Hacker News Reader

Comment by stupidcar | Hacker News Reader

I agree with the article in general, but the wrinkle comes when you encounter a bug in a large, popular open source project (naming no names, but any of the major web frameworks for example) that you're using for a work project.

Fix it? Sure, except despite their ostensibly open nature, many of these projects are run as internal projects of large tech corps, and the bandwidth and interest of the team in reviewing and merging external PRs is limited to nonexistent. I've submitted small, obvious bug fixes, complete with test coverage, to projects and had them sit unreviewed for years.

Fork it? Well there is a big, big difference between spending an hour fixing a bug and submitting a PR, and forking a large and complex dependency. You're committing yourself and your team and employer to the ongoing maintenance of the fork and merging of upstream changes, just so you can merge a bug fix. Usually, that's just not practical.

Fuck off? Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite. You may not even have been the person who chose them, but you're stuck with them, and then your boss asks you to implement a feature or fix something that relies on a change or fix in a dependency. Being blocked due to upstream intransigence is very frustrating, and there is often a professional cost to saying "no" to a request, especially a bug fix, no matter how convincing you argue that it's not your fault or under your control.

View on HN

If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you:

> This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.

(from the zlib license, but others have similar disclaimers)

If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them.

If you don't then no, the maintainer is not required to invest the time and money you are unwilling to into maintaining your pet feature or "fix".

You are right, but in practice that's not what happens. Companies do not rely on open source libraries, the developers working for such companies do.

I can give you a realistic example. If you want to use Kafka and Go, your probably only option is to use https://github.com/confluentinc/confluent-kafka-go. Its LICENSE explicitly says "no warranty". Now, what if I find a bug in the library? Only two realistic solutions from my side:

1. I submit the issue and hope for the maintainers to fix it

2. I dig deeper and try to fix the issue. I submit the PR

None of the above scenarios are guaranteed to have a happy ending. The issue could be ignored, or piled up among thousand of other (maybe higher prio) issues. My solution may not be optimal and could be rejected (or if it's optimal, nobody is taking a look at it, and it could remain open for weeks/months).

> If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them.

In the real world that would mean that I go to my manager and asks them to pay money to the maintainers of confluent-kafka-go to fix the issue I found. I don't think my manager would approve that, but let's imagine he does. The guys at confluent-kafka-go may not want money to fix the issue. These guys have probably already jobs that pay them well, and they work on the library at will.

Note: I'm talking about confluent-kafka-go, which I know is behind the Confluent software company. But I could as well be talking about libraries maintained by individuals like https://github.com/edenhill/librdkafka

But then it’s too bad right? Why should the maintainers care?

Because you release open source software to help others, in the same way others have helped you with theirs. Where has all the empathy gone?

I sometimes release software under an OSS license. I sometimes take patches from people. Other times I reject them because it's not the direction I want to take the project.

I sometimes use software under an OSS license. Sometimes I submit patches for fixes and they get accepted after appropriate amounts of reviews. Sometimes I maintain an internal fork for years before my fix lands. Sometimes I choose a different solution because my projects needs no longer align with the software's direction.

At no point do I ever think it's a great idea to bully an OSS maintainer into my way of thinking. I have all kinds of empathy for both groups but the rules of engagement here are very clear and anyone who thinks they should be different is just going to be hurt in the long run.

I release open source software so other people can use my work if it would help them help themselves. The code took some work and its nice for it to be known, but i dont have time to help anyone with anything, what with a corporate job and kids.

the people expecting more seem to be saying it would be better not to release code that one has no intention of helping people with, but that world is strictly worse.

Note that the baseline being discussed here, and in the article, is accepting a patch, not writing a bug fix or new feature yourself.

If every bugfix mandates a fork, the whole ecosystem becomes impossible. So the answer to you question is yes: unless you explicitly label something as a research project, one-time release, no patches welcome, we’re better off without it in the long run, as the sea of dead npm packages shows.

I guess I was picturing just a GitHub, but for go, that is the same as npm. I have gotten excellent benefit from gists only and for that matter code on stack overflow.

Still I guess I regard open source as more like twitch broadcasts than shopping for shrink wrap. If some one wants to take patches and so on, great but that seems extra to just releasing the code. The fundamental advantage of code is that it is malleable. That gist might not fit my project but if it solves the problem I can meld it into what I need so fast.

And a lot of bug fixes aren’t really bug fixes per se but are extra use cases, so a fork per use case doesn’t seem so bad. And I guess the advice for “person that wants a popular open source project” might be different for “just wants as much code as possible to be part of the common knowledge of humanity.”

I've had success asking for paid feature development on random GitHub projects the company I work for depends on. I had no involvement in the financial side of things though, just writing up the issues and verifying the results.

OTOH on another project where the company wasn't willing to spend money on commercial support provided by a company related to the project, they strongly tried to push us towards paid development even though I did extensive debugging on the bug we found and tried but failed to fix it myself due to the complexity of the codebase. Eventually they did fix the issue without paid support though, luckily in the interim we had a workaround.

If paying the maintainer is not possible, you can always pay some third party or hire more people internally to maintain the required libraries. If the company chooses not to pay anyone, it's a risk they brought upon themselves.

Not really the point, but in case this is describing a real issue and not just a hypothetical situation: I've found sarama to be very responsive to bug reports and patches.

One of the tragedies of the popularity of Open Source is that companies have become used to not paying for software dependencies. Back in the 90s when I got started it was much more common. In fact companies liked paying because that contract usually came with real life support from the vendor, and that was seen as peace of mind.

That's still often the case in enterprise environments. There's a reason companies use Openshift instead of plain Kubernetes (despite it being a bloated mess), or Redhat over Debian, or Sqlserver instead of Postgres, ....

In the specific case of confluent-kafka-go I’ve had to make extensive use of the second F. Trying to get the major improvements I’ve made into upstream has been… challenging.

Of course that F comes with a substantial maintenance cost. I’ve moved onto other projects internally at work and still every month or two I’ll get roped in to deal with some confluent-kafka-go releng issue or some such.

Tried giving them money too but confluent were pretty explicit with us that go was a low priority client library for them. I guess I’m not really saying anything other than I agree with everyone else in this thread, there’s no magic answer, only tradeoffs.

What's wrong with option 2?

It doesn't matter if the PR is accepted, rejected or ignored, you have a working fix that you can legally use forever.

once you have the PR, just point your code to your PR branc. it will be fairly easy to pick up changed from the main repo from time to time anyways.

Especially in corporations, do not make your project depend on things not under your control, or you will stop shipping.

Funny. The repo you linked has a very explicit 3rd option: "Supported - Commercial support is offered by Confluent."

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.

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

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

this. As a dev, this is not your problem. If you had a dependency forced on you, and that dependency has issues that the maintainers are not willing to deal with, then escalate the problem to your manager.

Of course, if you included a dependency because you thought it was a good idea, and it turns out to not be a good idea, then that's a different problem. You'll have to let management know that you'll need some time to refactor the code to remove the dependency. That could be a difficult conversation, but the answer is still not "hassle the maintainer to fix my problem"

> "hassle the maintainer to fix my problem"

Who is proposing that it's a good idea to hassle the maintainer? Most of these interactions go awry when someone decides to be an asshole. The tone of the article which says "fuck off" demonstrates the interpersonal impulses at play here.

Choose who you rely on wisely & try not to get into bad situations. If the maintainers of project x have an ill disposition toward the community, then consider it a red flag.

It's really simple: Harassing people, who explicitly waived liability in a manner that agrees with the law, is never an okay strategy. That is not to say it can't be very attractive in the face of personal adversity or be very effective, in getting you what you want. Just it's never okay.

I am also somewhat puzzled how we are having a discussion about this on HN, where adherence to open source licenses is usually a virtue. Only as long as our work is not negatively effected, I presume?

>I am also somewhat puzzled how we are having a discussion about this on HN, where adherence to open source licenses is usually a virtue. Only as long as our work is not negatively effected, I presume?

There are a lot of people on this site. Some of them may think differently than others, there is no way to fuse them into a single persona.

But that is exactly what we do by upvoting, statistically. There is a body of prior work to look at. Our collective stance on oss or mass surveillance is clear, and you can infer the resulting upvotes with certainty, statistically (might actually be a fun game).

The spirit of hn has clear biases and it's not equally open-minded towards all ideas.

A tiny subset of the site's users have accounts to vote with, and even less make use of it let alone make comments. Any guess about the "average" would be quite inaccurate. The stance of a vocal minority on X can be quite clear on a given thread, but even that is just the opinion of maybe 20-40 people.

And this is assuming there is no point manipulation at play, which is not the case for any popular site. In my opinion points alone can't be taken for more than a slight grain of salt.

I simply cannot fathom the idea of harassing someone publicly on the internet to deal with a professional issue I face.

In fact, at every company I've ever worked for, damaging the company's reputation by doing that would have lead to far more serious issues at work than just finding a workaround and documenting it well - and then, if suitable, contributing back to the project with something helpful.

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.

Then do not use kubernetes, if its complex enough that you cannot afford it as a dependency, with all that entails.

OSS isn’t supposed to be anything other than what the license says.

>OSS is supposed to be a collaborative environment where everyone can contribute a little

OSS coders doesn't owe you anything if they don't want to be collaborative. you already getting the code for free. you are paid to deal with these Open Source software. you can always buy the commercial software if Open Source is not doing what you want.

> not a “fuck you, pay me” environment

i don't understand. if OSS coders offer an pay option. why shouldn't they get pay? you get paid to deal with Open source software by your employer, no? you get to eat 'cause you get paid to deal with Open source software, no? why shouldn't OSS coders get to eat too? only you get to eat but not them?

You don't maintain a fork of the whole thing. You maintain a patch, ideally of an isolated area and now pay for the cost of maintaining the integration/sync of that patch until upstream merges or otherwise fixes the root issue. Depending on issue you can do this in basically clean, or ugly-hack kind of way.

At the end of the day, everyone must eat and put a roof over their heads.

Someone who uses an open source project in the course of their paid employment doesn't have standing to accuse volunteer maintainers of being overly motivated by money.

Our team does do cutting-edge work with Kubernetes, and we run into this situation quite literally all the time. How do we handle it? We're being supported by a multi-billion dollar business and we have the resources and talent to a) code around the deficiency, b) pivot to find something new, c) get in touch with our contacts at Google, actually use those enterprise support contracts we pay $$$$$ for, or d) make our own stop-gap solution. Every single one of these we've employed at various steps in the last few years.

Where you're mistaken is in not understanding the difference between FOSS and Enterprise OSS. You're describing a collaboration environment that can and should be present in FOSS. (but sadly often isn't) With OSS... you better have your checkbook ready. It very much IS a "fuck you, pay me" environment, and if you don't have the cash, you really shouldn't be messing around with Enterprise OSS. Use, and support, Free, by that I mean copylefted, Software. Build on Proxmox, not on K8s.

FOSS is a software commons, Enterprise OSS is a giant collection of walled gardens. You have to pay me to maintain Enterprise OSS. I'd maintain FOSS for free. You can't apply the dynamics that underpin FOSS to Enterprise OSS. Enterprise OSS is not written for you. You're not its target market. Enterprises want as much as possible to offload the massive costs, so they fund software foundations like the CNCF and the Apache project to do the core dev work so that teams like mine can have a stable base to build on and relative career stability.

> OSS is supposed to be a collaborative environment where everyone can contribute a little, not a “fuck you, pay me” environment.

This is a gross misunderstanding of what open source is. Please read the licenses that come with the OSS software you use. The authors and maintainers do not owe you anything beyond what the license says.

Who said anything about “owing”? If you write a book and I send you a note correcting something in it, you’re right - you don’t owe me shit, but it would be pretty nice to get a response. I find these views extremely cynical, a little niceness works both ways.

Since you agree that the maintainers don't owe us shit, we are on the same page. I guess I took issue with this -

> OSS is supposed to be a collaborative environment

OSS is supposed to be what the OSS authors and maintainers want it to be for their project while satisfying the terms and conditions of the license they have chosen for their project. It does not have to be a collaborative environment. Yes, it will be great if it is. Many authors just don't have the time to do collaboration after they have made the initial few releases. But that does not stop others from collaborating on it or forking it and improving it.

I am sorry if this sounds cynical. That's not my intention at all. I genuinely like that the open source licenses gives a lot of rights to the user while also including disclaimers that the author is not responsible for troubles you face with the software. Far from being cynical, I find it very beautiful actually. It allows the authors to be creative and publish software when they can without worrying too much about support and maintenance. Of course it would be nice if the authors also support and maintain the software and many authors do but it is good to know that it is not necessary and the licenses say so too.

I read that sentence as "where everyone can contribute a little [to the overall ecosystem]". Absolutely maintainers don't need to accept your contribution of a patch, and that's what forking is for - both are part of the overall banner of open source licensing.

OSS used to be more collaborative but these days it is corporate to the point you have to sign a damned contract to get a contribution merged. I am not owed better, I am just sad for what we lost.

Did we actually lose anything? Projectes that used to be collaboratively developed in the open are still being collaboratively developed in the open and as far as I see that is also the case for most new projects. Except those that are mainly developed by a signle corporation, often with a commercial offering - but having these in addition to more collaboratively developed projects ins't really a loss.

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

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.

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

Using software from Google or Facebook, it should have been known when making that decision that there is no influence you can have on those. These companies are run by psychopaths.

I do understand your point though, there will be many other software projects where the same issue is happening. I guess maintaining your own set of patches or doing a full fork are then the options. Or refactoring.

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.

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.

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

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.

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

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

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?

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

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

What’s your point? If you have a popular project and you won’t accept a valid patch, a bit of polite criticism isn’t going to hurt you.

Happened with the OpenOffice.org project. Caused the fork.

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

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

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

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.

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.

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.

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

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

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

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.

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

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.

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.

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.

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

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

It isn't that's it's not doing your part, it's that to think they are equal amounts of work, time, value and money.

Creating the Linux kernel is different to packaging an upstream Dependency. Or fixing a bug in a dependency.

You effectively owe the maintainer again for the work they do reviewing your work. Something that takes them away from their free time and other issues.

Sure both are hard and valuable but they are not equal difficulty or value.

The company earns money based on the revenues produced by the software that uses the maintainers product. That money goes to you as part of your wages and you think a bug fix is enough to compensate for the maintainers additional time for looking or merging your bug. Do you see now how that might not be reasonable or fair? Your balance debt to the maintainer is negative even after your bug fix. Especially given money is involved so it's doubly negative.

You also need to think of the time and money the maintainer spent in addition to the work to produce the initial product. So there you are even more indebted to the maintainer.

You’re looking at this as a one-sided transaction. The distinction between producers and consumers is not clear cut, especially if you consider only the subset of developers who submit patches.

In reality, unless they run their own handwritten OS, the roles are going to be reversed next week, where that maintainer benefits from the other person’s work (and salary as you say) through another piece of software. This is the premise of free software. Each contributes what they can, everyone benefits.

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.

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.

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

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!

> If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you:

I don't want to say "easier said than done" but... imagine doing `npm install` for like... Webpack, React. Start adding a few React related libraries

You're talking exposure to... hundreds (thousands) of "free" open source projects.

Obviously nobody owes anything to anybody in terms of "let me dedicate my free time away from my family/friends/my other hobbies/my personal sanity" to make sure the package I publish online is as perfect as possible. It just gets muddy/gray.

Is there a sense of entitlement for the unpaid generosity of library providers? Almost surely. "You published something, it got popular, now you are telling everybody who needs help fix it yourself or f*ck off".

It's just a weird source of conflict. People publish packages hoping they get used/become popular. Then they got popular and get overloaded by issues/requests and either embrace it or get combative.

This software is provided 'as-is', without any express or implied warranty

You're creating a distinction where there is none. Commercial software has the exact same disclaimer.

> Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite.

How is this the maintainer's problem?

Exactly

I think you should make sure, before choosing a dependency (framework or otherwise) that it either has the level of support (free or paid) that you require, or that you can easily replace it with something else that does or that you can build in-house (in case the maintainer won't merge your patches).

If a dependency fail to satisfy that requirement, it means you cannot afford it, even though it's apparently free.

Now from your description, it seems like you are paying someone else decision of choosing a framework the company could not afford, which sucks (as any situation where you inherit someone's debt), but in any case it's hard to blame the framework maintainer for that poor choice.

I mean, if the framework maintainers spent a lot of time marketing the product as being more reliable and getting more maintenance than it in practice now seems to you, it's pretty easy to blame them... but it still doesn't get you anywhere.

For small changes, there can be a fourth way between the fix and the fork: maintaining a _patch set_ for the official version. One ecosystem where this happens often is the Linux kernel.

The practicality of this depends on the nature of the changes and the rate of upstream conflicts. But if you can automate the application of the patch, maintaining a "fork" can be a much lighter affair. It would be nice if patching was handled as a first class dependency mechanism by high-level build systems (e.g. npm, cargo, maven, etc.)

The standard build functions in Nixpkgs can apply patches, e.g. https://github.com/NixOS/nixpkgs/search?q=patches

This article is written for you, yet you still can not see the problem? Think about it for a moment.

* Does the maintainer have any obligation to you, or anyone else?

* Are you entitled to anything at all from the maintainer?

* Is the maintainer in any way at all responsible for your "professional costs" for using their software?

You're completely right, but I think the point the parent comment was making is that big OSS frameworks like React in JS world, Spring in the Java world, Android/Flutter in mobile/UI and many more are basically central to applications. You can't switch away... If they have a bug and refuse to fix it even when you submit a patch, forking those projects is almost completely unfeasible (in the case applications run on their platform, like Android, it's impossible). Google and Facebook are not going to take payment from you to fix bugs they don't care about either. It's a game stopper...

The solution is, of course, not rely on any big-corp internal framework like that if your existence depends on those... but there would be a lot fewer businesses around if everyone did that.

That's the price of libre!

There are all kinds of articles that have popped up on HN about a company that did a rewrite because one of those frameworks was no longer appropriate for them. The article that come across the best are always the articles where it's not condemning a framework but instead talking about the engineering tradeoffs inherent in what we do.

If a company structured their software in such a way that this is more costly than they can afford them be transparent about it. Choices were made. Those choices no longer fit our needs. New choices need to be made. The company can either learn from the mistake and pay the costs or they can slowly sink under the weight of bad engineering decisions over time.

It is possible to structure any application in such a way that you can easily pull out your core pieces and put them into a different framework. If you didn't and instead bet too heavily on a single framework then yeah, you might be stuck with really expensive decisions.

This scenario is one of my favorite things about Ruby. In every non-Ruby project I’ve run there’s some level of forked dependencies because we need something fixed immediately, but end up maintaining the dependencies as we wait for the PR to be merged eventually, if ever.

With the Ruby projects, I can just monkey patch the fix into the original code without breaking the upgrade path. Wrap a test around it to let me know when the upstream fixes the issue themselves and we’re on our way.

Working with 3rd party packages is probably my top selling point for Ruby long term.

Agreed, live-patching can be blessing or curse, but this is definitely the champion use case for it

(still needs to be done responsibly, as you mention with test coverage and something to get you to examine and remove the patch when no longer needed. I also use https://github.com/Jcambass/sane_patch)

You can do the same in node using patch-package

The solution to the given problem with “fork it” is not to use any major dependency for which you aren’t already prepared to maintain a fork. The way to ensure that is fork it preemptively at the start of product development. I’ve maintained bugfix and feature forks of major dependencies with millions of lines of code, and not only does the merge from upstream become for the most part quite straightforwardly routine, I can say it’s much easier today using git than a vendor branch was back in the days of CVS.

There's a fourth option: Pay them. Pay someone to prioritize and fix your issue. You mention a work project, a work project is a commercial project, and a commercial project has money to spend; money it SHOULD spend. Either on you - to fix and/or fork it - or someone else.

We use an open source mobile app framework and we have a guy on retainer for 8 hours / week for just that reason.

Fork out, presumably.

If the upstream project does not want to merge your fix, but it's an obvious improvement and a non-controversial patch, then one option is to have packagers carry the patch instead. For example in Nixpkgs, it is quite easy to patch an upstream project. If you then want to step in and keep the patch rebased, that's great. If you throw it over the fence and later the patch starts to conflict, then the packagers would likely remove it. It shouldn't be the first thing you try, but it can be a valid alternative with unworkable upstreams.

You don't need a fancy Nixpkgs setup. GNU Patch works just fine and its 37 years old.

It works fine for applying the patch, but then you have to manually follow all of the build steps, turn it into a distribution package, etc. With Nix it is easy to edit an upstream package that already knows how to build the software, to include the patch.

I have been doing this with the Arch Linux AUR for many years and it works well too

> You're committing yourself and your team and employer to the ongoing maintenance of the fork and merging of upstream changes, just so you can merge a bug fix. Usually, that's just not practical.

Seems easy enough to build a custom fork in your CI and use that in your deployment. You could even automate the merge from upstream once a day. How often do you find merge conflicts in practice?

Many projects aren't pure library deps. If you need to fork a CLI tool for instance it tends to be a lot more involved. Even pure library deps can be a pain depending on the version manager you're using. Also, I often need to use a temporary fork even if I'll get it merged later, because the fix blocks something I'm currently working on.

Forking, when there is good tooling, is really nice. I wish tooling and practices were more mature. It's often a lot more hassle than ideal.

The tooling being used is also mostly open-source, and you have the same options - and difficulties - there.

The more people complain "but it's hard", the more they demonstrate how indebted they already are to those who have made open-source what it is today.

I didn't read the first F the same as you. It could be worded better.

from: "You can choose submit a patch and fix yourself"

to: "You can fix your local copy for yourself and optionally submit a patch"

I agree. The fourth F is 'Figure out a workaround'. Wrappers, control processes, plugins. When Terraform decides it's going to be user-antagonistic and not fix problems that literally everyone complains about, we have to create entire projects to work around it, like Terragrunt and Terraformer.

All of this is why you get paid. The alchemist turning the free stuff into stuff worth dollars! And bridging the impedance mismatch therewith.

Other options are changing libraries, changing the “requirements” or in a recent case in my company submitting a fix and waiting the months for the review and finally getting fixed for everyone. And yes it is a lot of work to do that in a complex OSS project.

If you don’t like this I recommend architecting to avoid it. Avoid front end libraries and use .NET for the back end which gives you fully featured system without needing as much FOSS reliance then pay M$ for top tier support.

Then just patch if after download. Maybee from time to time you need to change your patch a little bit. But in the end, thats the way when the maintainer is doing nothing for you. Think about it as, you tried to help them fix a bug. When they don't want your help, all what you supposed to do on open source software is done.

Question! I'll assume your employer is paying you for your work project. For example, if you fixed the bug yourself, your employer would pay you for your time. If the maintainer fixes the bug, should your employer pay them for that work?

The answer is obvious. If your employer is the one road blocked by this then pay the maintainers. If they don’t want to, then fuck off.

I can’t believe the level of entitlement of some of these replies. These are largely people giving you their work for free. You have no rights to their time.

I would probably treat such corporate "open source" project as free (as beer) proprietary ones. The only options are either accept them as they are or ask the business level to involve. The blog is more about real (aka community) open source as I see it.

If the problem is a business issue for your employer, then the complaints about time and cost fall under “or pay someone.”

If the employer cannot afford to pay then the business is simply not viable to the degree the problem is mission critical.

You are literally describing their sales model.

It is a fishhook constructed between an implied social/free project and a corporation’s revenue source.

You took the bait.

Indeed. The other side of this article is:

"Open Source Owners: Accept the PR, Reject the PR. No fuck off option."

Reply on news.ycombinator.com