In most contexts in society, getting something for free, seldom comes with great scrutiny or serious entitlement from the receiver. Logical of course, as you “got it for free”, and maybe also were told “given as is”. For open source however, the story is often quite different. Ever since the birth of online forums and online hosting of projects through platforms such as GitHub or GitLab, people’s easy access to critisize others have gotten the best of them. Many maintainers have been plagued with unreasonable critique. Expectations about always being available, fixing bugs at all hours, or going out and beyond the actual license, as if it was some red carpet hotline service occur a little too often. 

In many ways people’s VIP expectations are borderline comical, as using open source code is free and available for anyone to use. It is not a business model, it is not an employment model, and it is not a revenue model. Making commits to open source is not the same as the work one does when getting paid at a dayjob. So why has this entitlement paradox gotten such a strong foothold among certain users?  

Open Source is not the same as big corps

While some are deliberate jerks, others might be just unconscious ones. Having limited knowledge about the community and what it means to be “open source”, they might unconsciously be making comparisons to paid software and the support you get there. As unreasonable as it sounds, comparing one developer’s unpaid work to the work of one hundred paid ones probably happens more often than it should. 

Another aspect is how the critics hit. Being criticised from time to time is a natural part of being a big company. But as opposed to open source projects, big companies usually have dedicated people to take the hit - customer support staff, call center reps, even AI bots. Plus, the criticism hits the company, not necessarily some random individual. Most find it acceptable when our huge corporate employer faces criticism. It's fine, as we're mostly there for the paycheck. But if you do an open source project it is different. For some, that's their life’s work. And all of a sudden, someone who took your life's work for free is acting like an entitled jerk customer, cussing you out for that one bug or that one missing feature. There's no customer support person to take the hit. No huge corporation that you can deflect the criticism to. It's just you and your beloved hobby project that are getting shredded by some random person online. That might not be equally easy to take.

Likely reasons people act entitled

As already mentioned, some might just be plain out jerks, struggling with their own, personal or employer-related issues, and divert this frustration over onto some innocent soul sharing free code for the collective good. Thankfully the majority of users usually are grateful, and often decide to speak up if it goes too far. 

There are however some mitigating elements that may explain the jerks’ reactions, showing that it can stem from both systemic factors and the failure of maintainers to set healthy boundaries.

The "GitHub Effect" - Lowered Barrier to Entry

Some argue that platforms such as GitHub and GitLab have made the process of submitting an issue or request too easy, eliminating what used to be small, but effective barriers. Like needing an account or joining a mailing list, which previously filtered out low-effort or low-quality noise. The lower barrier however attracts more people who basically have no clue and demand support.

Maintainer Self-Sabotage

Another point that is mentioned in some fora is that maintainers often unwittingly encourage entitlement by blurring boundaries. They start to respond to out-of-scope feature requests, and as a result, fail to enforce the core principle of their open-source license, setting wrong expectations among users. These expectations can unconsciously transfer to other projects, and eventually feel like common practice, creating an unhealthy climate. 

Misunderstanding of “Open Source” at its Core

A lot of entitlement often ignores the limiting nature of the open source philosophy: Users are entitled to the code under the license, but nothing more, especially not ongoing maintenance. If someone releases code then that's it. You have it. Do what you want with it, within the boundaries of the licence of course. Unless the maintainer specifically promises to maintain it for free, you are entitled to nothing more than the actual code. 

Dodging of Organizational Liability

Companies using free software sometimes try to transfer the liability risk onto the maintainer by pressuring free support, treating the open-source project as a commercial vendor. Whether this stems from misunderstandings, an attempt to ease their own workload, employers pushing their employees in unsustainable ways, or straight out capitalistic forces in motion, can probably vary. 

Misdirected Blame - Features That Can’t Be Delivered

Some users complain about missing features that are deliberately excluded due to legal or ethical reasons (e.g., DRM removal tools). With lack of knowledge, some users see this as a failure of the software, rather than a necessary boundary.

How to handle the jerks

So how do you handle the jerks? 

Simply speaking, there are both proactive measures and reactive responses you can take. Things that reduce the chance of jerk entitlement in the first place, and approaches and tools on how to handle it, if it occurs.

Proactive measures - Setting Expectations and Boundaries

Enforce the License as a Contract

Basically be more “corporate” to protect yourself. Maintainers should actively take the “no guarantee of fitness for purpose” part of their license more seriously, and not fall for the temptation of being everything for everyone. The only thing maintainers really owe their users are consistency in license and project policies, and documentation that explains those policies. If you have docs that explain how the project works, how to submit, what submissions you potentially will accept, and any timelines - if any, then any reasonable user coming along can know what to expect. If those users then have unreasonable demands, then that's on the users, not on you as a maintainer.

Be Clear About Funding

Be clear and unapologetic about the project's funding needs. This can be phrased politely: "The core team doesn't work on unfunded feature requests because they use up a lot of time and resources." A stronger stance is to state that PRs will not be reviewed without funding: "Unfortunately we don't have the time to review PRs without funding... you can sponsor the project or contract a maintainer." Or for support: “Support that is not related to bugs, must at a general level be requested as paid support.”

Define Scope and Direct Users to Plugins or Forks

Even though you may want to serve everyone, it could be smart to ensure that features which are legally ambiguous or niche are available only through community-maintained extensions or forks. This clearly defines the core maintainer's responsibility, and helps them focus on the core product while ignoring “noise”. The maintainer can direct users to create a fork if it is a feature they really want, that is not supported elsewhere. 

Reactive Responses - Managing the noise

The “Just Say No” Policy

Strict boundary setting is something many are bad on. When facing unproductive engagement, like demands over naming conventions or feature disputes, the most effective reactive response often is to immediately shut it down, block offenders, and refuse to engage further. Why should you give in to a bully? Especially if their demands are conflicting with all the proactive measures you have already taken. 

Ignore the Entitled Jerks

It may seem banal, but sometimes the best approach is trying to ignore the noise from entitled jerks. As a maintainer you don’t need to respond to or try to convince everyone. Sometimes ignoring people can essentially be more effective than entering into a discussion. 

Enforce Templates and Processes

Similar to the proactive measure, “Increase the friction for interaction”, using templates can be beneficial. Simply saying “Please use the template when submitting an issue”. People may try to circumvent it, but at least you have communicated how you expect them to reach out. Additionally you as a maintainer can implement technical changes to make low-quality bug reporting harder, forcing users to follow proper procedures (e.g., spending "significant effort" to prevent logs from rendering in screenshots, thereby forcing users to upload the plaintext log file).

Find a Community Moderator

Certainly not a realistic approach for everyone, but if you reach a certain size these kinds of resources are out there. Find a community moderator you trust who wants to do all the customer-facing stuff. It will help you a lot with focusing on building out new features, rather than having energy-draining discussions that don't take you anywhere.

Final notes

At the end of the day, it is all about appreciating the contributions you make as a maintainer yourself, while, clichéd speaking, finding motivation in learning and growing as a developer. At the same time, you should take the necessary proactive measures and make the necessary reactive responses. As one Reddit-user said, “I don't think I've ever seen a shitstorm arise from clear and open boundary-setting by maintainers.” While it might not be completely true, there is definitely something to it. 

That said, most people and developers probably just want to do the right thing if they are given the chance. I also believe most open source users are grateful, supportive and at least somewhat aware of the enormous work-loads many maintainers face. More often than individuals, it seems like systems and cultures push people over the edge and past breaking points. Therefore it is important that we together try to rebuild dysfunctional systems and cultures, so they to a larger extent meet maintainers’ needs. Open source deserves it to continue prospering in the future.