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.
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".
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.
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.
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
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?
> 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.
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.
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.
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.
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.
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
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 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 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.
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"
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.
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".
> 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.
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 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 ...
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.
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.
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."
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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
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.
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.
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, ....
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.
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.
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.)
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.
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)
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.
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.
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.
> 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.
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.
As an OSS maintainer for a large project I disagree. Sometimes people did fuck off and it didn't do the project any favors.
I needed people to communicate clearly and with volume why I should change some opinions. Ultimately, my mistakes led to a competitor that was indeed unsuccessful but sucked a lot of the mindshare so we both got screwed.
We're smart people but we all need to learn humility occasionally. I do agree we need manners but I don't agree that people should just fuck off. I want complaints. That's how I can gauge improvement. A culture of ignoring complaints is bad. I know that is not what the article is about exactly, but it's where these things lead.
Nowhere it said you can't argue for your fix/change in an open issue.
Just that once the maintainer close the issue: `So should you get angry and start abusing them? No.`
Edit: And nowhere it makes any comments on how much/little the maintainer should listen to issues just that once he closed it you need to respect it and move on.
I had that. It was unpleasant (to say the least) but on a different situation I rejected a direction. User went elsewhere and we all ended up losing.
I disagree with the attitude expressed there. Don't like it. Build your own. Every maintainer has his style, I don't think that's a constructive style and as a maintainer I never use that style. I might disagree with someone, I will never say fuck off. Even if I think someone should fork, I will offer help with the fork, at least in advice.
Writing the code isn't where it ends. I thank every user who uses my code. Otherwise it's just another code dump. The users are what makes the work worthwhile. To me.
I'm glad to see this attitude expressed in the current sea of "reluctant maintainers". I don't really get why so many people get stuck maintaining a project when they don't want to maintain it. Just step away? If someone else wants to take it, they'll take it. If no one wants to take it, it'll just peacefully die, and that's fine.
Or if you want to run a project with no issue tracker, that's also fine. That's how most of the closed source Windows freeware programs were ran in the late 90s/early 2000s. Once it stops working for most people's use cases, people will just switch to something else. Granted, this model lends itself more to full products and not libraries or frameworks.
But if you want to become the "Hot New Framework", one of the ones that all the devs talk about, one that will be picked by teams across the world, with all of the clout, prestige, speaker invitations to conferences and whatnot that will get you, I'm sorry, you need to hold your end of the bargain. The mindshare doesn't come for free, if you get upset and take your ball home every time someone points out a bug in your code or requests a feature, the other kids will just stop playing with your (formerly) fancy ball. And as you found out, if people don't come with the right feedback and said feedback isn't taken seriously, your project's popularity will dwindle and perhaps even die altogether if the flaws or missing features are serious enough.
You'd think this much would be obvious, but the "Don't Talk to an OSS Maintainer Ever" doctrine keeps getting more and more popular and it's really bewildering. Being an OSS maintainer for a project out in the open means that your (volunteer) job is literally talking to people. Firemen may be volunteers in many regions, but if a random fireman randomly stopped putting out fires because "I don't owe you anything!", they'd be rightfully kicked out. Just because you're not getting paid, it doesn't mean you have no moral duty to anything in life.
RMS would famously shout "YOU are the GNU Hurd maintainer!" at people who asked him what GNU's plan for Hurd was. That obviously turned out great. It's a good attitude to have if you don't want anything to happen and just want to claim the moral high ground, it's not great if you want your project to be successful and it pains me that we're teaching people that it's ok to be unprofessional at volunteer jobs because you're volunteering.
> But if you want to become the "Hot New Framework", one of the ones that all the devs talk about, one that will be picked by teams across the world, with all of the clout, prestige, speaker invitations to conferences and whatnot that will get you, I'm sorry, you need to hold your end of the bargain.
This part goes without saying. If some maintainer does not want to do this, the framework will not become popular.
If you are an OSS maintainer who wants to build a succesful project used by a lot of people and companies and that has much mindshare, etc. etc. then yes, you will need to evaluate people's opinions, listen to them, and decide when it's in your interest to fix something or change the design or whatever. Because then keeping people interested in and using your project and in fact growing their numbers is your goal, so obviously you will need to attract and work with them.
If you released some code you wrote that was useful to you and sometimes update it or fix it for others because the fix is easy or helps you too or you just feel nice, then the calculation might look a bit different.
Then turn off the issue tracker and DON'T call yourself an "OSS maintainer". Or leave the issue tracker open but make it explicit on your readme this is just a personal project that's not being actively developed so people adjust their expectations.
Personal projects or unfinished work on GitHub are perfectly fine and in most cases, better to the world than something stashed on your hard drive, but you're not running any OSS project there. Feels to me some people want to have their cake (claim they "contribute to open source" on their CV/interviews) and eat it too (not have to actually do any work that comes with running an OSS project).
You say you disagree, but you are actually discussing a separate (even though related) issue: the maintainers' options in these situations.
The article does not say "just fuck off"; it says it is what you should do if you have exhausted all reasonable attempts to get your preferred outcome.
I disagree with the tone. I have never said to anyone to fuck off or even anything remotely like that. There was one case where I had a serious unreolvable conflict. I think that's a problem and very much not something to be proud of.
I don't tell people to write the code on their own or fork.
I think maintainer is a job. It's a volunteer job. Yes. I have allocated hours for this job. But I need to treat users as I would treat paying customers. That doesn't mean accepting their every whim. Never. But it does mean that the "job" is one of communication and community building. Not just of coding. OP seems a bit too focused on the code and too little on the people. To me the value of writing the code is the way people use it differently than I intended.
I take your point, as I thought it was a bit brusque myself. I attributed this to the author going for the alliteration, and perhaps also thinking of the final response to someone who is being unjustifiably and abusively demanding.
>> “I needed people to communicate clearly and with volume why I should change some opinions.”
This is not how real world works. People rarely intentionally communicate unclearly — or fail to add the “volume” they feel is necessary.
Only aspects that are in your control are: how you allow people to communicate with you - and what you do with what they share.
- Problem with how is that the more constraints you add, less likely they are to communicate; you’re basically increasing cost for them to reduce the cost for you.
- Easiest way to increase the efficiency of what you do with the information is to have another set of eyes helping process the information; in doing so, you’re delegating control and adding overhead — but gaining a predictable interface to filter less predictable information.
Communicating information takes energy, and there’s only so much efficiency that’s reasonable to expect, especially when dealing with random people via systems you do not fully control.
I gave a talk once on a piece of code I wrote and mentioned that an OSS library my project depended on lacked a feature. I wasn't so much complaining as just stating the fact that it didn't do X and it would be really awesome if it did X.
Afterwards one of the maintainers came up and asked me to make a bug report on Github. So I did.
I lack the expertise or time to implement this feature and the feature is still not implemented. But it's useful to have the feature request on Github because other people find and there are a few comments on it now.
Documenting stuff like this is important for maintainers. It's when the documentation turns into a form of harassment that people need to fuck off.
I will never understand the concept of competition in the context of open-source. I would love to have my projects be superseded by something better that is someone else's doing and responsibility.
This created fragmentation and both our projects ended up smaller than they could have been. They got a lot of attention but no money. Ended up closing source and dissolving. We're still running but lost a lot of mindshare during that time.
You’re allowed to run your project any way you want to achieve your goals.
But I think the post still applies. If I use your project, it’s up to me to communicate bugs clearly and in a manner useful to yourself if I want a chance of getting it fixed. Otherwise, I shouldn’t expect anything or go and do it myself.
That's true. I'm saying there should be a discussion and a positive attitude.
At the end of the day there might be toxic problems where someone will get pushed out. But I think these are things we as maintainers should feel bad about. It happened to me once and I feel sad that I wasn't able to resolve those problems. OP seems to be flaunting/celebrating what to me seems like a failure to communicate and build the community.
I formed a company around it. Entitlement is 100% true. But I don't ask people in the OSS project if they are paying customers or not. I also work on other projects where I don't make any money.
I think entitlement sucks. When people phrase things as a "demand" it's pretty terrible. But keep in mind that the internet doesn't covey emotion properly.
A maintainers job is a community service job. Even if you volunteer (which is this case), either do it with an open heart or just don't do it at all. Otherwise this will be pretty frustrating in the long run. You will burn out and fizzle because you think of all the time wasted where you could have made real money.
If you think about it that way... Well. Answering kindly to someone whose abusive and communicating your perception can make a huge difference. I did run into the very very rare a*hole that couldn't be reasoned with. But this is extremely rare. Most people just need to be talked to and heard. We can then work together. I can't be everything to everyone but we need to form a community of people who might not agree on everything. Those IMHO are the most interesting and valuable voices in my community.
> But keep in mind that the internet doesn't covey emotion properly.
This is not inherent to the internet. It's perfectly reasonable to expect an adult to convey their emotion appropriately over text. It's also perfectly reasonable to expect an adult to not be an asshole or a jerk on their first message somewhere, especially in a public forum.
I hope as an industry and society we can get closer to a place where people who act that way are shot down quickly and severely.
I don't. It's a big world and people won't learn without some compassion. They need to be shown the right way to behave. When you "shoot them down" you create hostility and animosity.
I get it. It's very satisfying to give someone what they deserve. But is it the right thing for building a community?
I think about that a lot when I have political arguments too. The toxicity level is so high and people keep pushing it higher. I just had a bit of a flamewar with a guy on a different forum. But we were able to end it amicably because we didn't let it get down to name calling and I was never disrespectful. I wasn't always able to do that, it took a lot of practice to reach that point.
To be clear, I don't mean "You came here angry and said mean things once, you're permabanned." More like "You're being unprofessional and disrespectful. You're more than welcome to return after you've calmed down but abusing volunteers and generally being a jerk is not necessary and won't be tolerated."
OK. I think the tone of OPs article is very problematic and sets the whole relationship between maintainer and user onto the wrong foot. The direction should be the exact opposite.
Even if you're paid, they're still not entitled to your time, unless they have a contract (support, hosting, etc).
As an OSS dev on a small project, when I started getting paid (part time, for specific things), I tried being nice with everyone, but people didn't understand the limits of what I could do. They'd get frustrated and abusive. I'm more careful now.
the list of abandoned open source projects because the maintainers burned out is I think a lot longer than the list of projects that ended because low quality complaints were ignored.
Literally go through GitHub and look how few people contribute the source code to even large projects. If they lose it, it often does significant damage to a project because original creators are important.
In a sense being rude is being humble. If I'm rude to bad complaints it's because I'm realistic about my limited capacity to deal with stuff. It's ironically often generous people who end up resenting what they're working on.
>In a sense being rude is being humble. If I'm rude to bad complaints it's because I'm realistic about my limited capacity to deal with stuff. It's ironically often generous people who end up resenting what they're working on.
??? I don't know how you define rude but I see no reason to go from something like `I'm sorry your suggestion do not align with my vision of the project` and close the issue to anything more insulting.
None of us measured this. Personally, I write code for the people. The good and the bad. It's very rare when someone is abusive (it happens). I'd say it's one in 1000. The ratio of people who disagree is much larger. The challenge is in creating a big tent environment that listens to everyone.
This sort of "don't like it so get the fuck out" attitude is poisonous. It might not seem so in the short term but it is in the long term. As a maintainer you're a politician, not just a coder. I need to be able to take some reasonable level of abuse and stupidity. Because occasionally I'm the stupid person who didn't "get it".
> the list of abandoned open source projects because the maintainers burned out is I think a lot longer than the list of projects that ended because low quality complaints were ignored.
The list is the same, because a healthy project grooms people to take over if you're burning out.
There's (at least) four Fs, and the first in the list should be "File it".
Not every open source user is a developer who can Fix it or Fork it, but a well-written bug report (and other forms of high-quality feedback) is a godsend. Even as a developer, everybody benefits if I file a bug and then spend my energy on my own open-source work rather than spending that same amount of time trying to learn the codebase of every piece of software I use.
I think that's because maintainers consider tickets as action items for them personally instead of treating them as feedback documenting known issues(sometimes with workarounds) for their users. I think DeVault put it very well a while back: a ticket is the place where the community can gather and exchange feedback on a perceived issue with a project (I'm paraphrasing).
I find that I do this less than I would otherwise, because I'm not sure if it will be interpreted as a demand that they fix it immediately, either by the developer who may already be dealing with entitled users or just feel compelled to help users of their software, or by random passer bys who use open 'bugs' as a metric to attack people with.
It would be neat if you could contribute information on issues, suggested fixes, workarounds with some guarantee that it was in a format that would actually help the maintainer, rather than stress them out.
Usually I just end up spending a reasonable amount of time thanking them, explaining that what I've noticed isn't a big deal for me, just something I think they might want to be aware of etc. But some systems should be put in place for this, like being able to tag issues as "I see this bug too" but also seperately "this is important to me" so widespread, but low priority issues can be prioritised and information gathered.
I really don't understand OSS maintainers that encourage or require people to fix or change things themselves. For a small patch the work of ensuring that the work of a new contributor is good enough is easily greater than just writing the patch yourself. And the time the contributor spent is likely much more.
Give me someone who does enough work that they get well acquainted with the code, or none at all.
For anyone in doubt, I'm saying this as a maintainer, random people's patches on average suck. Taking those patches is likely to cost me more time than they save. So why would I be adamant about encouraging strangers to write patches?
Personally for me, the most exciting releases I have has for the OSS software I maintain are the ones where I was NOT the one who contributed the most code. Not only is my code used, folks thought of it enough that they wanted to help!
It is great if you can get the right people. But if you have someone who just needs one bugfix/feature so they can get on with their own thing, they are rarely the right people.
The person in this case clearly want to contribute, so spending time on them may be worth it in the long run.
> It is great if you can get the right people. But if you have someone who just needs one bugfix/feature so they can get on with their own thing, they are rarely the right people.
I think Linus' point is you never know. If you shot down MRs from other people, I am not at all surprised that you have not found the "right" people. I have found bugs in other projects with other projects. I will poke around at the source, and to see if I can fix it, but I also look at the MRs. If I see that sort of hostility towards MRs, I just don't bother.
On the other hand, with the projects I maintain, I have found that encouraging folks to submit their own MRs, even if it costs me more time to fix up their patches, more often than not, encourages them to help out more, test/report bugs with useful debugging more, and even contribute more (in either code or in the community)!
Unless it's time-sensitive/critical, from the point of view of an OSS maintainer why should it matter whether a patch took 3 days to develop, or 3 minutes? As long as the quality and correctness is consistent across those patches, as a maintainer I'd encourage a wider base of developers who are fluent in my codebase, even if their initial PRs took slightly longer.
On most larger projects the 3 minute fix is more like 10-20 minutes depending on workflow, and they have many such issues in the backlog already. And most of the people who know your issue well enough to fix it that quickly are unpaid volunteers using their limited free time.
If you can ever actually encourage someone to fix something themselves, they just became a developer. They now have a non-zero chance of fixing other issues, or otherwise contributing. So it makes perfect sense to try and encourage people to contribute themselves, whenever possible.
What doesn't make sense is insisting when you could actually fix it yourself, you have time, motivation, etc, you just feel they don't deserve the fix.
I wonder if that is language dependent. For C segfaults or Go panics, usually the obvious fix is the fix and at least the stack trace is extremely valuable that people wouls want, if not the author than any one wanting to fork and fix. Python usually people have more subjective opinions, at least in my experience.
Maybe a project in Java and web/JavaScript just tends to attract form over function people.
"We should migrate the whole project to use this framework."
"The whitespace does not conform to this style guide."
"I don't care if it breaks on old Androids, we should use all the new JS/HTML/CSS features, and I have already begun converting the code."
Sure, but I'd much rather "interview" someone who is actually excited about contributing than someone to whom it was simply the only way of getting what they needed.
I think there's another side to this, which is that if you're the maintainer of some open-source project and you actually want your software to be successful and widely used and generally to make the world a better place, you're going to need to maintain a good relationship with your users.
When people report a bug, that's actually valuable. They're telling you something for free that you would otherwise have had to devote time and effort on validation / quality assurance to find. If someone requests a feature, that's telling you something about what users want (even if you might have perfectly valid reasons to decline the request). For every random email you get, there's probably a hundred more people thinking the same thing but didn't write the email.
I think if I were to contact a maintainer of some project and they sent me to this page, my thought would be: "oh, I guess this project is just a hobby project someone uploaded to github for posterity and they're not actually interested in maintaining it." That's okay! Not everyone has time for that.
> I quite often get bug fixes, patches, requests and questions regarding the things I have published. Most of the feedback is respectful and helpful. However occasionally there are other requests. This page is where I plan to redirect them as a final warning before I block and ignore them.
I will say that in my own experience with online diplomacy, you should just block and ignore them before sending them something that in context is telling them to "fuck off". As soon as you engage with language like that the civility is already over and not worth talking.
Honestly, the title is catchy, but this article is not phrased diplomatically enough to send to a difficult person.
When a reckless driver is on the road, the worst thing you can do is retaliate and aggravate the reckless driver. No, you should just let the lunatic drive by and hope he forgets you were even on the road.
I think the page sends a mixed message. The title is "fix it, fork it, fuck off" -- if I were a user, I would get the impression that the author might consider me rude or ungrateful if I were to submit a bug report without a corresponding pull request to fix the bug. My bug report might be in the "helpful" category, but I don't know that in advance.
It's work to maintain projects and if you're getting it for free, what does the owner really owe you in return.
Bug reports, feedback is useful and valuable but the initial work by the creator is where the true value is.
> They're telling you something for free that you would otherwise have had to devote time and effort on validation / quality assurance to find.
You also got the initial product for free and you're using the time of the maintainer to review your things, for free. There's unfairness in the exchange of a low value thing compared to a high value thing. The maintainers time is valuable.
You wouldn't trade £100 for £1, so why do you expect maintainers to drop everything and look at your "free £1"?
> "oh, I guess this project is just a hobby project someone uploaded to github for posterity and they're not actually interested in maintaining it." That's okay! Not everyone has time for that.
Someone took time to build something, uploaded their work (for free) for your edification and you expect more. Something is wrong with this thought.
> You also got the initial product for free and you're using the time of the maintainer to review your things, for free.
It goes both ways. The user isn't owed free stuff from random people on the Internet, but by the same token the software maintainer isn't owed users. If the maintainer wants users (which is to say, if the maintainer wants other people to invest time and effort using the software) they'll have to work for it. Some projects do want to have a lot of users and are willing to put in that effort, and those are the projects that make me want to use their software. Those are the projects that are making the world better off.
Dealing with people is hard, though, and it's perfectly understandable that some people don't have time for that. And if a project already has more bug reports and feature requests than its maintainers have time to deal with, then adding more is just making the backlog bigger.
> You wouldn't trade £100 for £1, so why do you expect maintainers to drop everything and look at your "free £1"?
It's not a zero-sum interaction. If I report a bug, there's a pretty decent chance that the maintainer wants the bug fixed as much as I do -- fixing the bug is not a favor they're doing for me, it's a favor they're doing for me, them, and everyone else who uses the software. On the other hand, maybe I'm the only one affected and it's not a high priority for them. That's for them to decide.
> Someone took time to build something, uploaded their work (for free) for your edification and you expect more. Something is wrong with this thought.
Is it? I think I'd rather live in a world where people have higher expectations for software, whether money changed hands or not. I do think though that it makes sense to hold large projects like Firefox or the Linux kernel or OpenSSH to a very different standard than something somebody did in their spare time. And it's worth keeping in mind that there are a whole lot of different reasons why free and open source software projects exist, and some of them have commercial business models and substantial funding and some of them don't. Sometimes it's not even obvious which is which if you're not intimately familiar with the project. Just because users of the software aren't paying directly for its development doesn't mean that no one is.
What I take issue with is the demands of users, they're not the people doing the work.
If I'm doing the work and not getting paid for it, I decide what I work on. The users demands are an input, which has a value which is more than 0 but less than my freedom's value which is worth more than 0 to me.
We can all expect and want better, the question is the same people with the expectations are not the people doing the work and especially not the people paying.
In other words, you can demand whatever you want but if you're not prepared to put any effort into it, why should I?
It costs nothing to have an opinion or expectation or demand but it doesn't cost nothing to do the work required of that demand. There's no such thing as a free lunch and work isn't free.
Why should I drop everything for YOUR wants and demands? Who gave you that authority?
You say that as if the users are doing the worker or maintainer a favour. Objectively, adding users to a project adds more work to a project.
The favour is going to the users, not in the reverse direction.
I don't like it when people think they're doing me a favour when the reverse is true.
Users overvalue their value and underestimate their costs to the maintainer and don't want to pay for their costs. People are difficult.
> if the maintainer wants other people to invest time and effort using the software) they'll have to work for it.
I take issue with this, you're essentially saying that the maintainer pays again in effort to get users, to benefit users. What exactly is the maintainer getting in return for having users besides users? More work.
Real bug reports are obviously valuable, Sadly though, a lot of "bug reports" are actually just disguised troubleshooting requests, that are unique to the reporters use case or infrastructure. Looking at any popular GitHub repo of a service that requires some form of environment configuration, half of the issues can be attributed to the user not reading beyond the first bullet of the Readme or didn't even bother to look the logs. You also see a lot of "How can i solve ${HOMEWORK|JOB}_ASSIGNMENT using this tool."
Those don't really apply to the 3 Fs anyway, it still add noise into the issue tracker and shortening the patience for maintainers to address real bug reports.
My experience with open source is that I find an issue, I fix it, and submit a fix, but the fix isn't good enough and the maintainers ask me to write it better, but at that point I am no longer interested since I already fixed my issue.
It is not like I'm going to start maintaining a fork over it. I am just not going to update the software or I'm just going to keep my patch in.
No. Because unlike the one contributing a "not good enough" fix, the maintainer now has to carry the burden of continued maintenance of that fix. If that fix makes that worse, declining is absolutely reasonable. Of course that's different for fixes with just a typo-level of complexity.
Of course it is! It's up to the maintainer to decide! It's their problem, like, literally! Of course, this should not be an invitation to blindly commit and push dumb fixes, even if they solve some problem. But generally:
> If that fix makes that worse
... then it's up to the maintainer to politely ask the contributor to make the fix better, or make it better themselves, or bugger off, meaning, then ...
Imagine you ran a personal twitter account where you posted your jokes but allowed people to send theirs via email and occasionally publish them. Would you find inappropriate to tell people "yeah this joke almost kinda works but it's not funny enough for my account maybe send me a better version"?
It also puts you in that weird area, where if you take the half-finished joke and polish it, then you're stealing and/or ruining their idea. Meanwhile, if you were looking for a long-term joke-writing collaborator, then you want to encourage even the people with enthusiasm but sub-par jokes to try harder in the hope they grow into the role.
If the jokes are kept in GitHub, you can modify the joke and rebase. Include a changelog section in the amended commit. "Original" authorship is retained. When it's merged, the committer is noted in the merge commit.
But I think it's harder to determine what has changed between multiple rebases. It rewrites history, as it's said. However, I hear the reflog keeps it somehow...
GitHub keeps track of this. If you go to your commits, your own merge commits of joke-polishing would show up alongside your own.
It's heartening though that an exchange between maintainer and contributor could be like that of a maintainer and future maintainer.
The code maintainer (or owner) makes the code available to the world without asking for anything in return, but if you send him a patch he is somehow obligated to implement it? (I'm not saying this is what you're implying)
Open Source goes both ways: nobody forces you to use some rando's code off of github but also nobody forces said rando to to use some rando^2's patch for his own code
Yeah, nobody is forced to do anything, but humans are weird social creatures and feel pressure to do certain things even when not externally forced. If people were just doing a robotic cost/benefit trade off then this wouldn't really be an issue, instead both sides get a bit emotionally invested in it.
I'm not sure you can compare code commits to jokes (occasionally such is the case), but I wonder what the thought process is when a maintainer decides to do exactly that and declines a fix that fixes a problem wrong.
If the contributor is not interested in having the change merged then yes. But there might be good reasons for the contributor to have the changed maintained by the project maintainer, so many will choose to make the requested improvements (was in this position multiple times).
I know this isn’t a one-to-one comparison, but there’s an interesting discrepancy in how HN views free-to-use products.
In this situation, there is a prevailing attitude of “You are not paying for this, so you are not entitled to fixes or support. Any suggestion otherwise is entitlement on your part. I don’t care that you’ve grown to rely on this service. Pay me or figure it out yourself.”
When it came to Gitlab considering deleting old free-tier repos, however, people were incensed and insisted that there is an obligation to continue providing free service for users.
Similarly, with Gmail and YouTube, people often invoke the argument of “this is people’s lives and livelihoods, so of course there is an obligation to provide fixes and support.”
So is the difference here that one endeavor is done for profit and the other isn’t? If an open source project becomes profitable for the maintainers, do they now have a obligation to fix and support their software?
> So is the difference here that one endeavor is done for profit and the other isn’t? If an open source project becomes profitable for the maintainers, do they now have a obligation to fix and support their software?
Yes, doesn't that seems reasonable? Presumably Gitlab became as popular as it did only because they offered free-tier repos, and generated revenue another way. YouTube only became popular because they offered free content and generated revenue another way, and so on.
Suppose you managed to start a company with a couple of loyal customers, and then as you grow bigger you ignore those loyal customers' needs in deference to newer customers that pay more. Maybe it's "good business" to pursue more profit, but kind of shitty to spit in your original customers' faces no?
The article makes no allowance for things like loyalty or obligation.
In this framework, if you don’t like how Gitlab, YouTube, or Gmail is treating you, then you can use a competitor, build your own replacement, or suck it up.
> The article makes no allowance for things like loyalty or obligation.
No such obligation to users exists in open source. The open source developer is his own customer. At best, you could argue there's a reciprocal duty to your fellow contributors, but I don't see how you can extend that any further.
By contrast, Gitlab and YouTube only became profitable because of the free contributions from others, and your views that YouTube monetized, so in fairness it seems like there should be some reciprocal duty there.
You're uncovering this visceral reaction to paying for things people use or want and expecting people to do things on their behalf that only benefit them.
Also the free rider problem.
Also examples of the 1% rule and Pareto principle where most value must be produced by a very small number of people and used by lots of people.
Disclaimer: I write open source software and I use open source software.
It's a non-useful and self-damaging trait that most people seem to have: yell at others to try to make them behave in a certain way where they can instead take actions on their own to ignore/avoid those behaviors.
This shows up all the time at work where people complain that they are getting too many slack messages or emails. You are not some hopeless caveman who has no idea what a computer is. Set up a filter and send everything you don't like to trash. Silence your notification. Mute/leave channels. Oh right, you are also a software developer. Write code to automate the above.
> There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter.
Block the user on GH/Twitter! Lock the conversation. Write a script to do the blocking for you automatically (Twitter and Github both have APIs for that - that should be a hint that this is an intended use case!).
If you have already identified someone as an abuser, any response, negative, positive, dismissive or otherwise, is only going to encourage the behavior - that is a well studied pattern. Writing a post and having it end up on HN does the exact opposite of what you hope it would. Someone reading your post is going to specifically go out of his/her way to fuck with you.
To be honest, I think the real issue with OSS is the whole masquerading of acting like a corporate project and almost red tape attitude that some maintainers have that can block a PR for weeks or months.
Unless you are a very important client who is paying money to the maintainers or unless the project is OSS but let's say, backed by/open sourced by a company like Google (as in, not some unknown person who kind of answers to no one) the chances of meaningful contributions landing are effectively zero.
If you are a client of a given library working for "Unknown company 8965688" and you are using a library and make a PR with a change you need or request it, in my experience, you'll simply be ignored.
Then comes the original post: we'll fork the library to an internal repository, make it our own, and stop depending on the whims of the maintainers who care absolutely nothing for the people who request features precisely _because they are actively using the library_ and need an improvement.
OSS has become a really, really bad place to be when it comes to actively depend on something that is managed by someone who simply doesn't care about you in the slightest.
Then, as we have people competent enough in the technology, forking becomes the natural thing to do.
Merging that PR can take a lot of time for testing, and also risks locking in some feature into the project, which the maintainer does not need or use, but they're now stuck supporting (owning) from here on.
Typical conversation:
- contributor: I need feature X for my big client, it's super important, please support it.
- maintainer: interesting, I'm not familiar, but I'll take a few hours to review. Can you help maintaining it? write tests? help fix other bugs?
- contributor: no. corporate does not allow me to. I am too busy, have other paid projects to work on, why would I do things for free?
Don't get me wrong, everything I do is FOSS, but it's easy to be brunt as a maintainer.
Why do maintainers owe you support? I assume by your comment that you're a company, in that case, since you're making money off the value added by that OSS project, financially support the developers to get support in return. Then you can act entitled :)
I often have to use open source projects in my work (Backend Software Engineer), there are projects that are popular, many of them backed by companies themselves and there are small one-person projects.
As an engineer/developer, you may have an issue with one of these libraries, tools, etc and you'll put in a ticket with all of the details your development expertise can coax out; sometimes you'll get responses of thanks for a clear report, sometimes you'll be ignored, and other times they'll disagree or be unwilling, and now you're stuck.
You'll go to management and ask if they'll pay said company/developer to fix it and they might, or they might not.
You either look for an alternative, write something yourself, or you fork it internally, fix the issue and move on; now you and your peers have another piece of code to maintain because nobody on either side of you would budge.
I've never been abusive to an OSS developer, I've certainly been frustrated, and I'm an FLOSS advocate myself.
Some projects I've worked with, and I won't name names, have turned around fixes in literally an hour, are greatful for a good thorough report and want their software to work for you (and I'm talking large internationally used enterprise grade tools), and others will just be rude or dismissive, but you still have to solve that problem, it's your job.
When I have a job to do I'll just move on from projects that make it harder, and I'll advocate harder for the projects that make it easier, if it's small and generally unmaintained, we'll just fork internally, improve 8t all we want and move on, now nobody in the wider community benefits.
There are other projects that are larger, and we pay them decent recurring sums to be able to ask for a fix or feature to be turned around quick, and it'll end up in their open source code, so everyone benefits from that money this company spent.
When you're a small start-up developer you have far fewer options available to you compared to a large company who can or will throw money at people inside and out to get things done.
>if it's small and generally unmaintained, we'll just fork internally, improve 8t all we want and move on, now nobody in the wider community benefits.
Everyone can still benefit, just make your private fork a public one. Of course you now have the same problem as the original maintainer in that people will make requests of you or fork it
Exactly, they're just posting code, but, simultaneously, if they put it in the public domain, they probably expect that the code will be used by others and from that moment, well, they are at least responsible for replying to PRs or close the ones they don't care about merging.
Once it's public and gains "customers" the responsibility grows a bit, otherwise don't post it at all publicly, after all, if you're not going to care about real world use cases, it's just as valuable as any toy project that hasn't seen the light of day.
This type of almost "passive gatekeeping" is the reason why we've formed several OSS projects we rely on. Yes, we incur maintenance burden but the predictibility gained is Invaluable.
A project being backed by a major company like Google is no guarantee of a well run project. For one project by Microsoft employees on GitHub, they don't appear to even read issues or trivial PRs.
> If your project becomes better it will naturally gain more attention and be more inclusive
Unfortunately, things don't really work this way. Maybe for niche software with a handful of users, but once a piece of software has gained enough traction it can be very hard to convince users to switch to a fork, it's not enough to just "be better".
This post sounds like it was written more out of spite than anything else.
Might be out of spite. But I wouldn't dismiss the idea. This sounds like redirected to the people who wants a certain thing in the app, and non-stop complaining after a WONTFIX under all slightly related tickets.
Rights of the owner has to be respected, even if they're wrong in the eyes of users.
Viscerally understand the sentiment as someone who handles vague technical feedback here and there, but I've also seen this attitude kill off project enthusiasm almost completely, specifically with D&D/pathfinder character sheet manager PCGen: https://en.wikipedia.org/wiki/PCGen
In an era before github issues, the project got a lot of requests via the Yahoo groups mailing list that were often of suspect quality, but usually addressing a real flaw with the software. At some point near the end of the mailing group's life cycle, the most active maintainers really took a shift in the angry direction, and I think that led to a lot of people on Reddit, rpg.net, giantitp, etc no longer recommending it.
This might not seem like a problem, but over a long enough long frame, low user interest for a formerly popular piece of software does seem to inevitably lead to a loss of maintainers.
> Heck even a tweet at the owner might be good enough.
I disagree with this, don't spam people. Sometimes people even go out of their way to contact you using multiple channels and it gets even more annoying.
Kind of depends... I'm listening to so many github repos that I often don't pay enough attention to the notices or even keep up regularly... if it's important/urgent, I'd almost preferred that they reach out via side channel. It's a rare case for me at least.
I know it can be annoying if there's too much of it, or there's too many vectors or if you or the repo are popular. I'm not.
This is sensible advice. But I'd add an "R" as a separate and important item: report it. In your report, provide a clear explanation of why you think this is a bug, perhaps speculate on ways to fix it, and perhaps volunteer to help, in a way decided upon by the author.
"Cold-call" patches and pull requests can be quite disruptive to an author who might be busy with other parts of the code, or (quite likely) with this part. They may be fine for trivial bugs with simple solutions, because the author can then tell at a glance whether they are going to cause problematic ripple effects.
But for more trickier bugs with complex solutions, stitching in a patch/PR can be quite a hassle for the author. This is especially so if the new code is formatted differently than the old code, or uses a different "style" with respect to variable naming, etc.
Start by reporting the bug clearly and respectfully. Let the author know, if you see the solution. Perhaps they will ask for a patch or PR. Or perhaps they will say they need a few days to look at it. Either way, start with a conversation.
Also, if you're putting a lot of work into a pull request and it's important to you that it get merged, knowing whether you don't have a good chance of success, in advance, is going to save you and the maintainer potential sadness about your wasted effort.
> There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter. All this results in is people wanting to not contribute their time and expertise for free.
> [...]
> Always remember you are talking to a real human being, and just because their ideas of how to implement a project are not in line with your own does not mean you have any right to abuse them.
I do not believe there is ever anything that gives one person the right to abuse another.
An excellent list! The once dominant Apache httpd is a fork. Never knew it. Postgres is a fork! Never knew it. Microsoft SQL Server is a fork! OpenSSH is a fork. The list goes on. I am sure that Wikipedia page, like many I have seen on code/tech, is under-maintained. I bet the reality of forking is much more extensive.
Finally, the title of the article makes me laugh. I knew it was gonna be good before I started.
The actual reason of this friction is that essentially, FOSS developers are working for free.
FOSS devs and maintainers don't have _any_ monetary incentives to continue working on a project unless it helps them getting their desired job.
Yeah, you may say some devs have so much passion about their software that they are willing to donate their time for free. But the interest may dwindle after a couple of months and years and that's when the whole thing becomes somehow a burden.
It may not even come down to that. One bad morning + constant pings of "any updates yet" by an entitled user may trip the dev off for good.
I made the mistake of making the Python module that handles Microsoft Word files (python-docx) about a decade ago. Despite including a bunch of examples for making, reading, and modifying documents, right in the README, I received a bunch of emails from India demanding I help them. I eventually passed the project onto someone else (not entirely because of this, I also started more involved with node at the time, but this was definitely part of it).
I think I know the type of interactions you mean, and I wonder whether it's a cultural thing or a language issue of which I am not aware: I have received a bunch of e-mails from strangers telling me something along the lines of "I request you to do X", where X is something related to a project of mine. I always tried to see this as a sample of "inexperienced person not expressing themselves politely." It's the most charitable explanation, but maybe someone else with more knowledge about the cultural differences can comment on this?
Some people are just completely shameless about demanding that somebody else fixes their problems for free.
I maintain a few small OSS projects and most of the interactions I have with people are pretty pleasant and respectful. However, my inbox is a dumpster fire of recruiter spam (both trying to recruit and offering their services to me), and incompetent idiots trying to sell me whatever. And indeed the occasional support request. It's infrequent enough that I usually reply if people are articulate and coherent enough (which is a problem with some of this).
Otherwise, I have a pretty simple strategy for all this: I don't dignify people with a response unless I understand what they want and it adds value for me. Simply, not worth my time and energy.
Repeat offenders get blocked and marked as spam. There's no point in me getting upset or angry about any of this. Just the price of doing business these days. In the same way I ignore the dozens of attempts at connect attempts on linkedin. If I don't know who you are and you don't have a coherent reason as to why we should connect, I'm going to ignore you. Buzzword compatibility doesn't count.
Here's a modest proposal. Your employer can no longer pay you, but they have a big code base that you wrote. You are now obligated to maintain that code for free. Think it through. How else can your employer get what they need?
You might say that they should pay consulting rates, or that you're busy with your new job. But how is that your former employer's problem? They used your code in good faith, they ran out of money, and they were forced to lay you off. None of this is under their control.
If Github would highlight popular forks better that would be a tremendous help. It currently is annoying to uncover if there are any relevant forks and what they contain.
It will vary... there's times I've created the PR myself, but cannot wait for the patch to make it in... so I'll reference my fork to start with, then go back and re-reference to upstream and delete my downstream once it's accepted.
I usually discover existing forks when looking for a bug/issue fix and see there's already a PR, that may have been sitting for a while, or rejected but the issue remains. Sometimes that means creating my own fork of the downstream for ongoing use.
YMMV, I usually do try to update the README to indicate it's a fork for personal use until upstream approves/integrates.
I think single issue forks should be presented in the Fork overview in a special way (for instance with the linked issue), but I was mostly talking about actively developed forks which are hundreds of commits further than the original project/upstream. Github should be doing more to advertise these for instance by showing the top 5 forks in terms of activity.
Also too many forks are just user interface mistakes where somebody wants to look at the lists of forks but accidentally forks the projects by clicking on the Fork counter in the top right corner rather than the Fork counter in the "About" box of the project.
Very much this. The most unpleasant part of running an open source project is feedback from some toxic users. Many of them behave as if you work for them, and demand all kinds of privileges, or else they'll give you 1 star rating on Google play!
Daniel Stenberg, the lead maintainer of cURL, has some interesting tweets about this topic. In fact several of the toxic comments he posts are from people who seem to lack a basic understanding of what the project even provides.
The post resonates with me as an OSS user and a contributor. Many a brave souls have taken to forking the project to fix the bugs but those forked projects almost always suffer from a discoverability problem. I have tried making fixes and tried forking projects only to discover that someone else has done it better elsewhere.
I've been burned by this problem often enough that I wrote a Chrome extension which would _tell_ me if there are any notable forks of the project I'm currently looking at on GitHub: https://github.com/musically-ut/lovely-forks </self-plug>.
What are the other requests that the author receives? This list seems to still include every option of interaction over an issue as being acceptable, so I’m not sure what behaviour they’re tying to discourage?
Basically the assumption that by sharing your work, you become inherently beholden to the wishes of those that use your work.
Some time over the last ten years or so, much of the open source community acquired the belief that they deserve to be treated as a customers despite the fact they don't pay for squat.
What were people doing based on that assumption? The article says contacting the author to ask for a fix over bug trackers, Twitter, etc is still ok in their mind. What else were people doing?
"Ask for a fix" is euphemism what often happens. It's commonplace to receive reports to the tune of:
* "Can we get an ETA on this? Some of us need to get real work done"
* "How you can justify leaving out such a basic feature?"
* "This project is unusable without this feature"
* "Why waste people's time by releasing software with bugs like this"
* "This kind of mistake is totally unprofessional"
* "The developers must not have the skill to fix this"
These sorts of interactions can be more exhausting than outright abuse, because they're designed to bait/provoke the developer rather than just insult them. And to be clear, this isn't particular to this developer. There was a whole study done on this that made the rounds awhile back[1].
The devil hides in the details: it is all about how much "critical" the set of components is, and what is the core of the pb being reported. Because, as my experience goes, often the pb lies with the "dev" of the set of components itself, not the issue reporters.
Software (open source or not) is plagued with planned obsolescence and software Rube Goldberg machines, and on components where it is accute, there is no reasoning of anybody, the "dev" is a scammer, not to mention the "dev" is often a corpo or an organized network of ppl (pulling the strings in the shadows).
On critical, big and/or complex sets of components, and those would be well established ("financing" is kind of "secured", and those components are used a lot), the "dev" knows that hardly nobody will be able to provide real-life alternatives, then "dev" may give you a bit of attention but will send you to hell if you start to threaten their scam (namely the "financing" of their network of ppl). Usually, you will get partially true responses missing out the "disturbing" parts, all that with a ton of "mauvaise foi", like a troll.
Fighting this can only by done on case by case basis since we are talking about complex component systems. Not to mention, mistakes can happen because it is easy to be fooled in complex matters.
Sometimes, you may have to "follow the money" and go legal.
So if I find a WebKit bug in the latest iOS beta, file it with both Apple and WebKit, and get ignored, I should just fuck off? I can't fork it (Apple won't use my fork) and it's unlikely my fix would be complete and accepted for upcoming releases, so I guess you're right. "Fuck off" and let iOS devices crash is my only option.
The only problem I see with the original post is a matter of diplomacy. As the saying goes, the trick is to tell someone to go to hell in a way that makes them eagerly anticipate the vacation. (Or using the original post's terminology, they're eagerly up for it...).
I would have expected that the discussion here should be taking that as a given. No paying business is required to take on all suggestions from all customers [1] [2], why would anyone be expected to do that for free?
[1] Paying businesses have whole departments dedicated to translating "tell them to go f--k themselves" to "Dear Sir/Madam: We would like to extend our deepest sympathy for your concerns with our product ... ".
[2] Another popular HN topic is "the client from hell". Would be interesting to have a thread to discuss this thread in that context.
I must admit that I used to be a harassing parasite. Then I realized how foolish I was being this way. I changed into just a parasite, but I feel urge to contribute and sometimes I do.
I also learned that those who harass, will learn one day the same lesson as I did, so I don't bother too much with them.
The author of this post conveniently neglects the fact that the third F also has a payment option: Pay someone to bug/sue/harrass the developer on your behalf until they succumb to preserve their sanity.
Out of all the payment options, this is likely to be the cheapest and most effective.
I can't argue with the basic argument of OP but if the project is still active but in the wrong ways (adding new features, add hype, etc) and still not fixing recurring issues then I have to put some blame on the maintainers in how they wish to spend their time. They are busy doing work to get their dep in the codebase you have to work on, but not enough time making it work well in said codebase. And as others have pointed out you often do not have a choice about these matters when not in ownership of the project. Of course none of this is an excuse for any kind of harassment. But public criticism of the library? Sure.
Great article. That final F sentiment is EXACTLY what the open source world needs. There's too many free loaders and mega-corp vampires taking advantage of peoples' free time. Some of this is beginning to feel slave-like. Billions in profits and vast fortunes are all on the backs of unpaid maintainers (slaves) toiling nights and weekends (cheap labor). And I'm just as much of the problem...Not giving back (financially or in other ways) makes you a douchebag and most of us are in that boat.
"Fork it" means a whole lot of additional problems: backport fixes from new upstream versions, build packages for your distro, maintain your repos etc.
Another example:
You contribute for 10 years for opensource project.
Familiar with code, all of you fixed dozens of bugs.
Community grows, opened issues - shrinks.
Dynamic to close all major problems very soon.
And when you feel absolutely the safe, some motherfucker comes to a place, and offer:
"Guys guys, let's switch our codebase from C to C++, because there are easier to work with strings, easier to work with pointers, easier to work with everything".
And big community without listening anyone by decision of 2 guys from community of 100 devs - moving code base from C to C++. All that they doing - changing extension for files, and adding `extern C {` to files.
Since that amount of bugs - increased dramatically.
Instead of fixing problems, there comes another dev and saying:
"guys guys, lib-json too old, let's switch to modern and nice YAML".
Yea, does not need to care, that we already have GUI for working easily with ANY data in the repo, all perfectly tuned, and everyone used too. and boom - devs decide to switch to this bullshit.
5 years pass since these changes (since switching to CPP)
What do we have now?
Community big slice of the communiy leaves from the scene.
Because this is impossible to maintain such mess
Another slice of community which is left - stay on codebase from 2017 without these changes.
Project semi dead, impossible to revive it.
Why all of that happened?
Because of idiots who have permission to apply final decissions to repo.
Repo of community driven project. Where all things done by a community, but merged by owner of the repo.
The project do not belong to the owner of the repo, the project belongs to community, the owner just in 2011 made a switch from SVN to github, and uploaded data there.
Sometimes - douche-bags = owners of open source repos.
And as a guy who contributed to dozens of such projects, this is not "sometimes". This is - usually thing when guys on what rely community project - let the project die by doing nothing or doing wrong actions.
I don't understand why open source developers think they are owed anything by anyone.
They chose to work for free and give away that work.
In the process they killed any proprietary competition and therefore a chance for anyone to get paid for the equivalent work.
Now there are users who demand that these developers fix the bugs they introduced during development or add missing features, and rightly so, since there is no other choice.
Users cannot just hire someone to do the work since that is going to be too expensive, more expensive than if they asked proprietary developers to fix the same issues since proprietary developers work would have been paid by many users.
Should open source developers be forced to work for free?
On the one hand the answer seems to be obviously no.
On the other hand, these developers killed all the competition that could have provided cheaper development alternatives for the user so maybe they do owe some free work to these users.
Compare this to other professions, electrician can install the wiring for free but they are still liable for any work they do that is not compliant with the relevant standards. They don't have to install more wiring for free but they have to fix any mistakes they made.
Software development is still a wild West of professions and it is in dire need of regulation. Then if it costs too much to work for free and release certified code, developers won't do it and users will pay to get a quality product.
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.