Entitlement in Open Source

It feels like these blog posts come out at least once a year. To me, the issue comes down to the fact that companies are fundamentally relying on software that comes with no promises of support or a warranty. I honestly can't think of another industry that relies so heavily on things they get for free and come with no warranty.

So many people act like Open Source is great. But often the love for open source often only goes as far as to say thanks when they're creating a bug report or when they're getting the software for free. Every company I've worked at has used open source code. Only one of them open sourced their code. Many non-decision makers wanted to do open source code but it was never given any time so it would always come down to "You can do it in your free time and release it under our name". So again the company wants free things that benefit them.

Personally, I think the way forward is source available. I have a SaaS boilerplate/product framework thing that I'm releasing under the Business Source License where it's free to use for non production and free for folk generating less than $5,000 a month to use in production[1]. To me this provides the best of both worlds, people who aren't making money can use it for free but those who are using it to generate money need to pay to help fund the development. Free users get best efforts in support and paying customers get priority support. I think if it relies on people paying what they can afford it results in many not paying at all even though they can afford it.

[1] https://github.com/getparthenon/parthenon#faq

With open source projects, you are "entitled" to do the following if you have a problem with the software:

1) Submit a bug report to the maintainer. The maintainer is free to choose whether to fix the bug, add it to the backlog of bugs to fix eventually or mark it as won't fix.

2) Fix the bug yourself. If you do this, you should offer the code to the maintainer. If they don't want it, you are free to fork the code and merge future releases into your fork. The task of doing such merges gets exponentially more difficult as the delta between your software and the original software you forked grows.

3) You can pay the maintainer or somebody else to fix it for you. This can involve paying for a support contract or a one-off payment. The maintainer still has the right to turn down your offer of money either because she feels the money is insufficient or because she feels that what you consider a bug is actually an important feature that shouldn't be removed (in the latter case, you can hire somebody else to fix it for you and fork it).

4) You can find a way to live with the bug.

5) You can find a different program to replace the program.

What you do not have is the "right" to demand that somebody perform any kind of work for you without mutually acceptable compensation or the "right" to send abusive messages to the developer(s) of the software. That kind of stuff shouldn't be tolerated especially when it is coming from corporations that employ skilled professionals who could just fix the bug or could easily just pay the maintainer to fix it.

I've read so many posts like this on HN. The crux of the issue is that, in my opinion, maintainers need to grow a spine regarding entitled user behavior. If someone opens an issue, and it's not currently in your backlog, tell them to pay up to move to further ahead in the backlog. Cite your hourly or per-issue rate.

If people don't want to pay, they can go elsewhere. You kill two birds with one stone, either they leave or they pay you, both likely good outcomes for you. But simply doing it for free based on their whims just encourages entitled behavior, and that is how one burns out.

Having worked retail, I know how customers will act when entitled, and with maintainers, it is abundantly clear who has also worked retail and who has not based on their ability to handle user entitlement.

This isn't unique to open source, the behaviors described are easily recognizable to anyone interacting with end users of SaaS or, really, any software. It does not matter how well things are communicated and how much effort goes in to change management, _someone_ will ignore the communication and insist that changes be reverted.

If you're interacting with users, it's important to publish crisp and defensible promises to end users and deliver on them (when these promises are backed by a contract, they're an SLA). Boundary setting is as much about what you will do, and delivering consistently, as it is about being comfortable saying no when the error is the user's. Stating clearly what you expect people to do (sign up for this email list, upgrade on this cadence) goes a very long way.

Policies and promises stated and delivered are usually enough to get people past the anger phase of grief to bargaining, which makes the interaction a lot easier to manage.

Homebrew has really wonderful maintainers. I'm mystified why anyone would get into conflict with them, but I can imagine the kind of entitled personalities who would do that. The article gives a hint:

"Ironically, this is often worse coming from employed developers’ large tech companies with fantastic profit margins."

This is exactly the main OSS problem right now. Entitled $BigCorp employees who churn around 1000 LOC (in OSS) per year for $250,000, engage in activism and high profile issues that will be talked about on Twitter and take credit for actually valuable contributions from idealistic individuals.

I think the story in the article is related to a big issue with Homebrew that's not so related to entitlement but to expectations: Homebrew's philosophy and default behavior is to keep everything updated to the latest version. This makes it OK (sort-of, at least) for day-to-day tools and utilities... but not ideal for systems.

I've been personally bitten by this before, where a Python script no longer runs because a library (libssl, I think) was updated to a new non-compatible version and one of Python's modules depended on it. This update in particular was caused by installing something else, unrelated to the program or project.

... So now I know this and try to use different ways of installing my projects' dependencies (and have disabled auto-updates). But a lot of people come across Homebrew when googling "how to run <blank> on MacOS", as it's the default recommendation everywhere. This is not necessarily Homebrew's fault or responsibility... but often there's a communication gap between maintainers who assume everyone should keep software up to date dealing with whatever breaking changes are published and announced and people who live on a completely different schedule and might be wondering why the script they run quarterly no longer works.

This issue is not exclusive to Homebrew, I think. Modern development (specially things like node.js / front-end) moves at its own fast pace, and long-term support is not its concern (or not long enough). Hopefully a healthier culture of long-term software maintenance will emerge, with patterns and practices that can be adopted to align everyone's expectations and obligations.

I believe the crux of this topic is way down in the piece:

> The problem is that these generalities turn into expectations of behaviour, those expectations turn into entitlement and entitlement turns into toxic behaviour that makes maintainers quit open source.

From the maintainer point of view: you cannot control your users, you can only control yourself. Therefore the solution is to use whatever tools at your disposal to guard against whatever is facilitating the transition from "toxic behavior" to "makes maintainers quit open source."

If maintainers can't avoid getting upset when users complain, there really isn't much to be done.

Seems like the real problem, as it often is, is package and version management.

Besides the open source authors and maintainers, has anyone considered that “distros” of open source is a thing? Companies have sysadmins and distributors may have a bit more time to manage exactly these expectations.

Why is Bob being affected just because Homebrew made breaking changes in a new version, especially if they used semver?

Probably because someone in Bob’s organization, whose job it is to watch for these deprecation notices, doesn’t have the information that Bob is relying on the old behavior. Yet Bob is somehow forced to upgrade to the new Homebrew because the organization “needs” everyone in the company to run the latest and greatest.

Well, that issue is between Bob and his company’s sysadmins. And those people should have some knowledge of what changes break what.

Actually, what would be nice is some sort of automatic AND STANDARDIZED tool that shows which interfaces are used by which clients in your organization (CLI, ABI, API, etc.) and what an upgrade would entail. Does such a tool exist ?

This is why I feel like it's important to maintain the distinction between "Open Source" software and "Free Software" even though, as a Free software die-hard I have to admit it seems like we have failed.

The original idea of Free software started when RMS wanted to fix a printer. Xerox said "no", and the the rest is history.

AFAIK the idea of "Open Source" started as a way to make Free Software more palatable to commercial interests. Businesses wanted to develop commercial advantages and not share them with everybody else. I have no idea personally why anyone ever thought this was a worthwhile thing to do, but then there's a lot of human behavior that I find puzzling. In any event, from my POV, we can trace entitlement in Open Source software to it's very root: the whole point was to enable people to use the software without contributing anything back.

Originally, the idea with Free Software was that programmers would charge money for making improvements and fixing bugs. (The idea of charging for copies of already-written software is not excluded, it's fine if you can pull it off.)

I personally figured we would program the computers to do all the work and more-or-less retire in a techno-utopian Star Trek scenario. (Again, from my POV I don't know why everybody isn't on board with this: "Let the robots do the work and we'll take their pay.")

To sum up, the whole "Open Source" movement (as distinct from the "Free Software" movement) is kind of self-contradictory: business has been encouraged to take advantage of the freely-available "Open" software, and so they did. But then the culture became one of entitlement (as contrasted with the contribution-based culture of the GPL).

Great read and points to consider.

In a similar, yet different, set of circumstances, what are reasonable expectations when you're an indie developer? And instead of it being an OSS Homebrew solution, it is an OSS library on GitHub that accepts sponsoring (and you've sponsored them before, simply because you get value from the library and want to show your gratitude)?

It's easy to hate on the big tech corp who doesn't pay for what they use, but what about the indie dev (and especially if they have paid)?

While I'm generally sympathetic to the points made in the article, I think one statement it makes is misguided:

"[R]emember and really deeply internalise the fact that you can stop working on any open source project at any time. Open source maintenance is a job and, like a job, when it stops working for you and you have better options, you can go elsewhere. You should not feel bad about this; instead, you should feel good about the fact that every contribution you continue to make or made in the past were good deeds given freely to others. When your life or the project means it no longer feels good to work on it anymore — stop."

Actually, the fact that you can just stop working on any open source project at any time, regardless of how many users it has, means that an open source project is not a job. In an actual job, you cannot just walk away whenever you feel like it, because someone is paying you to do the work, and you have some kind of actual agreement with whoever is paying you that you can't just break if you feel like it. If nobody is paying you for your open source software, it's not a job.

I emphasize that I am not saying that working on your own open source project in your own free time should be a job where you can't just stop when you feel like it. As long as the situation is made clear to your users, then it's on them to deal with it. But that very fact means that you should not be describing it as a job, because it's not. Your relationship with your users is not the same as it would be if the software were your actual job and you were being paid for it.

Entitlement will continue as the world adopts OSS further and everything is built on the shoulders of giants. People are lazy by nature and more willing to complain than send a PR or detailed enough issue for a maintainer to pickup.

The challenge I see is that maintainers shift their mindsets from the labor of love to be one that should be compensated accordingly. I wonder why and when that tends to happen? I have guesses, but mostly think it's a boundary issue.

The article basically nails the last point that seems overlooked on many of these projects:

> Finally, maintainers need to learn to say “no” again and again. No to new features. No to breaking changes. No to working on holiday. No to fixing issues or merging pull requests from people who are being unpleasant. No to demands that something has to be fixed right now.

There's definitely pressure from the world stage to say "Yes" to everything, but that's the trap that I think many maintainers fall into into trying appeasing the whole world and feeling fed up after they've had enough.

When people don't pay for anything they have no leverage and a lot of people turn into assholes to try to get their way.

Generally issues that come in through paid support where people know they're going to get worked on are a whole lot more neutral or positive. Issues that come in through the public GH tracker have a strong tendency to get passive aggressive really quickly.

The problem is bigger and I think “Bob” can be very damaging to “Reem”. If “Bob” ever threw a tantrum on the issue board while “Reem” quietly and politely shut his issue down he could get vindictive. He could in fact damage “Reem”’s career prospects if she were to apply into “Bob”’s company for a job. He could write damaging reviews that make it harder to attract contributors.

So in this example the behavior did not escalate. But if “Reem” is someone who does this in her free time and planning to use it as experience when searching for positions - “Bob” can have the ability to make her life quite miserable. I’m pretty sure those cases exist.

So while we think of how users are entitled and what corporate impacts exist. Let’s also pay some thought to the maintainers and contributors who spend a lot of personal hours on this. Be kind and communicate with respect and thanks.

Personally, I have felt that the current rate of software development across the entire industry is impossible to maintain long term. People are writing software faster than QA can happen, nothing is ever truly stable, and everything is always broken. Software is a fluid that will always expand to fill its container. That said, it's also true that software mostly works which is something I cannot say for software in the 90s. I suppose this one of those "miracles" of the industry. I personally hate the direction the industry is going though. Stuff seems to change constantly for no reason, desktop software is mostly just chrome in some form or another, and SaaS is eating everything. The only stuff that doesn't do this seems to be FLOSS, so I use it.

It may be time for me to sharpen other skills and make a career change, I dunno.

I agree with the message but wish they had picked another example.

If you remove a feature within just a few months of warning, users will be pissed. I think it is valid to feel frustrated about that. Its unrealistic to closely follow the development of every package you are using.

Now, I am NOT saying they are entitled to a solution. I am just saying, if you declare something stable (if you don't, do whatever you want) then you are creating a certain expectation and you should be very cautious not not break the expectation.

My intention is simply for the sake of the discussion to separate the two issues: There is the entitlement issue. There is also the issue of certain libraries and frameworks that keep changing things.

I think the views espoused in this article are not the best way to handle such situations. Bob should have pinned the dependency to the older version being used (assuming that can be done in homebrew) so that his companies usage of it can continue uninterrupted. However his team should also be able to properly identify and schedule the work needed to update the dependency. Having something just randomly break one day in production is not acceptable. If homebrew packages can't be pinned to an older version then that would be a technical difficency of homebrew itself.

One way to handle entitled users is to offer paid support option. We did that in BIRD project: https://bird.network.cz/?support

Perhaps we need a set of well-defined community engagement policies just as we have well-defined licenses or copyright policies, e.g.:

- patches/pull requests welcome or not

- paid consulting available or not (obviously with a right of refusal on architectural changes)

This would go a long way towards managing expectations and avoiding mismatch.

Tooling matters. Github doesn't have a way for a project to specify they won't accept pull requests for instance (e.g. thet's SQLite's policy, one I fully support, but then SQLite doesn't use GitHub or even git for that matter).

I feel for the person who wrote this rant but this exact problem has existed since the 80s (early days of the GNU project) and surely forever in other domains. Most people just think of themselves.*

On this topic I often mention bfox’s canned response to complaints about bash: “Please return your copy of bash for a full refund”

* remember this when writing a marketing campaign, pitch letter, or for that matter a report for your boss.

In the early days of OSS everyone who was a user was a developer and if you didn't like something, you fixed it (or forked and fixed it) and moved on. That's the answer really. An OSS user is not a customer.

Acting like an entitled customer should get you nowhere. There are paid models for that sort of behavior.

I use Homebrew frequently. It's quite useful, so thanks, Mr. McQ. It's not an "I can't live without" utility, but it is one that I'm glad to have, occasionally (a lot of CLI tools and whatnot, are best installed via HB).

I've been doing open source for a couple of decades (at least). The only real "hit" that I wrote, is now out of my bailiwick, and alive and well, in the hands of a great team.

I have encountered some fairly bad behavior, in my time, but having massive scale, and being deluged by requests, has not been an issue for me (which is just fine).

As far as I know, no one has taken anything I've written, and made themselves rich on it. I release my stuff as MIT (generally), so there's nothing I can do, if they do that. I just tend to write stuff that is "the same, but better," as opposed to "new paradigm" stuff. "Better" doesn't actually seem to mean much to folks, which makes me a bit sad.

I work in open source, as a hobby, I made roughly $200 in donations in 10 or so years.

I also know the feeling of people getting mad when I make a change that I believe it is good but others (users) hate it.

I agree and would like to echo chamber the issue that for every maintainer there are thousands of users that don't give back anything, not even a thank you.

I think our reliance on github causes us to have inefficient or ineffective tools to promote good opensource.

I think github sponsors has been a good idea but its execution is extremely poor. (Tl;dr it is ineffective and doesn't plug in the rest of the echo system)

There is some psychological aspect for sure in using open source code and not paying for it: the moment you pay you expect some entitlement over support and direction of the project, but I am know psychologist.

That being said this blogpost is great, but nothing ever changes as a result, sadly.

Maintainers complaining about entitled user behavior implies a business opportunity for an enterprise version of the software.

At the risk of being downvoted, this illustrates why paying for software is sometimes cheaper than "free" software.

His fictional story reminds me of the Homebrew 2.7 debacle: https://github.com/Homebrew/discussions/discussions/340

TL;DR: They deprecated "brew cask install" in version 2.6, then removed it in version 2.7. Sounds fine, right? Except version 2.6 was released on December 1st, and 2.7 was released 20 days later on December 21st, breaking everyone's scripts just before the holidays.

I agree with the overall premise, but there's a balance to be had somewhere. When millions of developers use your tools, you do have to be a little more careful when you make breaking changes.

I think Linus has a point here with his "don't break userspace" rule.

I see this from a different perspective. The developer using the API or tool has a valid expectation that their software should continue to work as-is for years even as outside changes are made to the underlying tools, libraries and features. The flaw here is instead, in my opinion, a willingness on the providers of these tools and libraries to pull the rug out quite frequently on their end users.

If there is a security risk, you can mitigate that by redirecting your users who still use the feature to what I'll call a "diversion" along with a warning that they will no longer receive updates and to consider the feature obsolete. Perhaps with a popup or console blurb that warns the user of the problem, this way the end user developers eventually do have to fix it because users will bother them about the issue.

I understand it creates clutter that maintainers would like to avoid, but the alternative is constant rug pulling that undermines productivity and the usefulness of your tool or library. You created your software or tool to help others whether for financial gain, altruism or ego boosting. I think you forget that when you decide to throw your hands in the air and rug pull. It is irresponsible and lazy. You are shirking your duties onto others.

We need a new system, process or design pattern to help alleviate this issue in our industry. Because end user developers and system or library developers are constantly butting heads over this. There is a strong smell here that needs to be resolved. It is a problem in search of a solution. I think we can potentially engineer our way out of this.

For example, if you developed software for the first Google Android phone, it no longer works on the latest phone. It should. Why wouldn't it? I wrote a piano app that no longer works, it would require a full rewrite and recompile. And, this isn't just between an ancient version and a new version of the phone. Just one SDK update and they've suddenly changed all of the interface names, function arguments, etc. Just because they thought a name sounded cooler or clearer. This is irresponsible design.

Microsoft does a great job with their APIs being backwards compatible as much as possible. But, the cost is having to carry a massive history of APIs and tools they can never truly sunset. If you develop something for the first DirectX SDK it still works on the latest release. Because, they number their interface names. I'm not saying this is the ultimate solution, but it is one way to address the problem. But, it has problems of its own.

I'd like to see a large effort to address this, we keep avoiding it as an industry.

two things I did cut this way, way down. For my most popular repo:

- changed to Noncommercial License [1]

- charge for issues. 9 USD or I close immediately. If someone posts something that is a genuine concern, I will address it. However minor issues or feature requests, you're on your own, unless you want to pay for my time.

1. https://polyformproject.org/licenses/noncommercial/1.0.0

Epistemic Status: Just musing out loud, I'm not sure I even believe this but it's one approach to the problem.

Open source software has some pretty severe networks effects. There's only so many people who are going to maintain a package for MacOs, in affect different package managers are going to be competing for those volunteer maintainers, and there's a pretty big first mover advantage. (there's only one wikipedia, despite it being pretty easy to make a new wiki, volunteers are the resource projects compete over)

If you're an open source maintainer who's part of a project driven largely by volunteer labor like this, well you've got to consider the fact that your project existing means that other project will have a lot harder time getting started. It's not as simple as "we're all volunteers so be thankful for what you get" because just by existing your project is consuming a finite resource, volunteers, sponsorships, awareness, etc. Your project existing might be taking up space that a much better project could fill. Of course if it's that much better it probably will eventually anyway, but still.

So I don't know, try to make sure your project is the best it could be, and try to build something that will last rather than chasing new features? I hear a lot about entitlement in open source, but with some projects I do wonder if we'd be better off if they just collapsed, and the sponsorships and volunteers moved to a different project. Not homebrew, I don't use homebrew but from what I hear it's all around decent, but there are a few open source projects that have become de-facto standards that I do wish just go phased out.

When X11 stopped being maintained in favour of wayland that forced a bunch of your fellow open source developers to make a bunch of changes to their code, foisted a maintenance burden on them. That's fine, things do change, but try to make it easy on them ( https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552... for example).

In a sense, isn't any kind of expectation you could have for open-source software entitlement? If your FOSS doesn't come loaded up with malware, crypto-miners, and a servo motor to punch you in the genitals, should you be thankful since it was free? What if it just comes with the malware?

I'd like to see some kind of social contract "maintainer responsibilities" that lists out what users are allowed to expect before they start getting called entitled. There's some basic stuff, like it being free from active malware and viruses. There's some more questionable stuff, like CVEs or some other method to subscribe to security warnings. There's probably some miscellaneous stuff, like being able to get old versions of the software (not having the author go out of their way to remove old versions like what happened with the infamous NPM left-pad story) and all kinds of other stuff I'm not thinking of.

what about 'Entitlement in Closed Source'?

"deprecation" kills Open Source projects, ecosystems, even private services. The people don't like to build their businesses, livelihoods on shaky ground that can collapse from under them at any point just by the decision of some maintainers who are doing something as a side-activity.

This seems to stem from the academic roots of Open Source. It grew from such projects in academic environments where deprecation of something would not cause anyone's business to collapse. Amplified by its adoption in large organizations in which deprecations don't cause major disruption and the organization would have ample time and funding to address these anyways.

This mentality even afflicts and hampers large private organizations - take Google:

A culture that has grown from its academic roots in MIT, where the funding mainly comes from the government or large military/private organizations. Carried over to the larger organization of Google as it matured, where there was ample funding and time for addressing such 'deprecations'. All good.

But they kept behaving towards their end-users in the same way. Constant 'deprecations', shutting down entire services on people's faces with little notice, literally giving a jolt to their small businesses, organizations, even livelihoods. Then they started noticing people earlier. But this didn't change a thing because the general public don't have the funding and resources that Google has for addressing such 'deprecations'.

So people started trusting Google. To such an extent that Google Cloud cannot get people on board even as their execs openly promise stability to the customers. Because nobody believes them anymore.

https://steve-yegge.medium.com/dear-google-cloud-your-deprec...

Actually, turns out Google itself also doesn't have such resources. As evidenced by the recent 'inefficiency' talk that they gave to the company. So much engineering. But not enough product, in the face of a tech sector that is increasingly imperiled by rising inflation and dire economic times that do not permit floating organizations on overvalued stocks...

...

If even Google suffers from this kind of 'deprecation' behavior, imagine how much general Open Source suffers from this.

Obscure feature or security updates causing backwards-incompatible changes and breaking entire software setups, small businesses and individuals having to dedicate considerable time to maintaining their software as if they were software engineers who were doing it as a hobby.

That's what's hampering Open Source. Treating everyone as if they were software engineers using the Open Source software on the side, as a hobby.

They aren't.

They are people, a lot of them non-technical, with real lives, businesses and livelihoods that hang on that software.

And that is the major reason why Open Source keeps losing ground to proprietary, closed-ecosystem services that just give the users what they need to run their businesses and their daily lives without having to deal with Open Source maintenance problems.

So...

> The lifeblood of volunteer-run open source projects, which is most of them, is ultimately the motivation of the maintainers who work on them

No, the lifeblood of volunteer-run open source projects are their users. If there aren't users, there is absolutely no point to an Open Source software other than being a hobby for those who get involved in it. The users include corporate or intra-organization users too, by the way.

With such a mentality, Open Source can never change the world. Instead it would just keep losing ground or stagnating compared to closed-source private services and ecosystems that prioritize their users.

This article touches upon a very important part of human nature that becomes increasingly counter-intuitive as you go along.

First of all, people will define things as valuable if they bring utility to their lives. But the perception of value of a thing is influenced to a disproportionate degree by the perception of its availability and scarcity. Almost everyone learns this sooner or later.

We also have the dichotomy between the moral perception of a job and its salary. Most people feel that [insert should be paid more and star athletes less (at least until comes the time to pay for that through taxation). Most people feel aggrieved that they are paid less than their fellow employees in the same company just because they live in a poorer country. We see the value a profession brings and feel there is something wrong. But to the holder of the purse strings, your value is determined by the ease of your replacement, not the value you actually bring in terms of utility. Capitalism increases the speed at which this adjustment takes place, but it would still happen in a pre-capitalistic society. I would say most people, but not all, are both aware of this and inform their decisions by it, even if it's via a cultural mechanism such as seeking out hard-to-replace professions.

And there is the more insidious example that your value as a human being is evaluated not just based on how useful or impressive you are but how difficult it is to access your time, energy, and preference. You have the classic example of a person regularly brewing coffee at the workplace. They mistakenly believe that doing something nice and useful leads to being valued. In reality, their coworkers now take the coffee brewing for granted. They do not respect the coworker more than before, and possibly respect them less because they consciously or subconsciously see their time as less valuable. If the employee in question catches on and stops providing that service, their coworkers are now unhappy with them, which is the opposite of the initial objective.

Of course, this is just an illustrative example and life doesn't play out the same way every time. But holding the general belief that people will consistently respond positively to spontaneously provided services is not adaptive because it ignores social status in favor of an illusion of moral reasoning and actual utility. In fact, you could argue with the coffee brewing example that it's a case of trying to sign people on to unrequited contracts, where you do something nice and thus believe they owe you when the premise is that they never asked for anything to begin with.

In the example in the article, something similar is at play. People use FOSS stuff because they have a problem they need to solve and see a free resource to help with that. But because it's so free and accessible, there is less automatic respect for the code and its maintainer than could be expected. The key aspect is that people like Bob don't even need to be an asshole or an unreliable worker to gain this sense of entitlement as it is just a natural mechanism that does not require bad intentions. The coping strategies the article cites are all great, but they focus on the angle of self-care and self-respect, which is only the first step in the equation. The final calculus should also take into account the reality of social status and the perception of availability. You do not get treated well because you are useful, but because you are perceived as a scarce resource whether it's true or not.

First of all, we have this blog post at least once a year, like top commenter has said. Second, uh, no, you're a moron. Open source now is just completely commercialized. Firefox looks exactly like a 90s garbage web browser that shows you some stupid page full of ads, and links to news with ads, on startup. I am an open source developer. I don't expect any gratitude for what I do, I just want to get shit done. People who pretend issues don't exist are annoying. If I am using a typical open source library these days, I expect it to be made by some guy developing it as if it's his job (and accordingly, with lots of corner cutting). Basically all these new sprawl of languages are a stack of half working bullshit from the build system to the GUI all made for clout or on a whim based on some idea thought of last night, or by some extremely inexperienced person. And the only reason none of this stuff works well is because open source devs are literally clout chasing and constantly move all their dependencies (also fixing invalid problems that shouldn't exist like RCE bugs). You're right, I shouldn't expect them to work at all.

I didn't even read your article, I have better things to do. The idea that people are "entitled" in tech is retarded and no spin on your title can make sense. Tech is a sea of festering rot piled up 100 times.

Well, if maintainers were not that reluctant to saying "no" to breaking changes, the stories like that would be few and far between. But let's be honest, maintainers do like breaking changes a lot, unless they are in stuff they themselves use.

It's also not true that every single programmer is like Bob to the tee, demanding, being outraged. I've seen issues that had been closed even if the reporter was polite to the extreme. This post is trying to describe a strawman, so when you hear any complaint about your stuff breaking other stuff you imagine an entitled prick. This is not so, by far.

In most cases, it's not like software is all well-oiled machine, except for that one tool. You have multiple libraries and tools that you need to combine so it all works, and because each and every one of them has quirks, bugs, defects, holes, you get to be generous with glue at places so it all works in the end. You tend to spend uncountable amount of time nudging them to work together. And all of those libraries, tools, applications, utilities are each moving at their own pace, having its own little ways, and of course having lots of stories about ungrateful users.

And guess what, the vast majority of them is silent. They see how swiftly are issues being closed, they are too tired to speak up. What for? You're going to close the issue anyway.

Those that speak up, usually are polite. In many cases, I've seen people going overboard only after maintainer had played dumb for a long thread of comments and refused to even understand what the problem was about. Few people go to issues to actually vent or demand.

In exceedingly many cases, you may only get your bugfix that you absolutely need, but it's inevitably bundled with new features you could totally do without, and regressions which make you think that life is only about picking your poison repeatedly, until you die.

In the end, all the stories of this kind end up about being egotistic pricks shouting past one another but refusing to ever listen.

I lost my hope to live in a world where we are excellent to each other, but maybe being good enough to one another would be achievable, wouldn't it?

Exploring this thought. Most of the time this argument surfaces, it’s from developers who are being paid (donations, salary, grants, etc) to work on the software. Why do we expect different behavior from end users just because the output carries the OSS designation?

If you’re getting paid to work on software, you should give a damn about your users, since without them you wouldn’t be getting paid. And it’s not like working on OSS is some kind of sacrifice; it’s not like paid work on an OSS project prevents you from also getting a job at a place like Google.