The Sour Taste of Entitlement

This is a companion discussion topic for the original entry at

Paradoxically I think KDE is a victim of its own success at marketing.

When you go to a soup kitchen, you’re under no illusion that it’s actually a nice restaurant. There’s no menu, no waiters, no fancy tables. The food is plain and hearty. The people eating it look down-and-out, like they’ve seen better days. It’s obvious what the place is.

But imagine a restaurant that served a wide variety of delicious food for free! It’s got the same “free to eat” distribution model as the soup kitchen, but everything else about it is upscale. If you ask for changes to a dish, the cooks will try their best to oblige. In this environment, you’d definitely get people acting like entitled jerks.

I think this is the challenge we have in KDE: we advertise ourselves as a free-to-eat fancy restaurant, not a take-it-or-leave it soup kitchen for the poor and desperate. So peoples brains’ are primed to be in picky entitled mode, not grateful mode.


You’re saying KDE spoiled its users with haute cuisine. You’ve got a point.

1 Like


What we offer is really weird, if you think about it: soup kitchen prices for food somewhere between the level of Outback Steakhouse and Chez Monsieur Pamplemousse. People don’t know how to react to this!

There’s a lot of fascinating psychological research about how especially for complex or difficult-to-value products (e.g. houses, cars, art, jewelry), people’s perception of quality is often greatly informed by the price they paid.

Rich people will pay 20 times as much for one of these things compared to a normal person and swear up and down that it’s better despite most pieces of evidence to the contrary. But they feel better! The higher price must be a signal of value, right?

On the flip side, when people get something for free, they’re psychologically predisposed to undervalue it even if it really is very good. Why would someone be just giving this away if they could be making a buck off it? Must kind of suck.

I’m not sure what the actionable takeaway is for us. IMO it bears ruminating upon.


We all use other open source software too, and I’ve definitely griped about things. I’m not sure it’s so clear cut.

I think a good metaphor is if you offer someone a lift to the airport and they take it. If you do so and that person complains about the music on not being their choice, or that your car is dirty, that person is a tool. They also can’t complain if you break down by accident.

But if you just decide you’re not going to the airport anymore and take away a feature, or don’t make it to the airport because you haven’t bothered to maintain the car the other person has every damn right to complain. You’ve let them down, even if it was free.

I find myself constantly referring to “making promises” when it comes to feature requests. From my point of view each time we make a statement on our public website or offer a feature in our UI for something we make a promise to the user and they quite rightly are going to rely on it. That opens ourselves up to critique if we let them down.


Loved it!

At which point, Jo throws the plate on the floor and storms off to go and complain on Reddit.

lol! I didn’t expect that end :laughing:

For me it should be: take it or make it better for everyone.

I believe it should be clear to people that most of free open source contributors are not saints or saviors of the “poors” but we mainly act for our own benefit. We just understand that we will benefit the most when we act in a collaborative way. Otherwise we can just sit back and wait from some corporate God to give us what we want. At least this is how I feel about it and I hope I’m not the only one.


One actionable takeaway could be to make Breeze uglier - I’m 50% joking.

Breeze looks beautiful, polished and comprehensive - IMO, moreso than any other modern environment, including Windows or MacOS. That creates an expectation of a similar level of polish and curation for the actual functionality of Plasma and KDE Gear apps - but I don’t know if that is achievable, or even conceptually compatible, with KDE’s goals and how it works.

GNOME looks hyper-simplified in its appearance, and delivers hyper-simplified functionality.

Xfce looks - and I mean this with all the love in the world - like what a Windows/Mac user in the year 2000 would imagine Linux looks like, and it delivers on that experience.


I think there’s something to this. Basically, we either need to downscale our messaging/presentation, or upscale our results. Obviously the former isn’t actually a practical option, but it’s interesting to think about. :slight_smile:

To be fair to us I think what we deliver generally does match the presentation for most users. The few whiny entitled people who complain about stuff tend to be the ones with the most complex hardware setups, the most intricate customizations, and/or the strongest and best defined workflow preferences.

In those cases I think the issue is they feel like they were sold “KDE offers infinite customizability along with system stability” which we don’t actually promise. Rather this is mostly a meme in the community, and often claimed on social media by ex-GNOME people burned by their shell extensions breaking all the time. They come to KDE and discover that once you tweak our system six ways to Sunday, maybe we’re not that much better than GNOME in the stability department. Which gets into David’s point of “every feature is a promise.”

And to be clear, most people with complex setups seem pretty happy overall! We’re talking about a very small minority of people here. But I guess it’s human nature to focus on the few complainers rather than the legions of satisfied people.


Hmm…so, this might be crazy/not practical, but what if some “promises”/features were gated in such a way that folks could choose - in the top Settings section, for example - between:

  • “Plasma Standard Workflow with Breeze theming”, with a sub-description of “Provides a curated look and feel for your desktop, with customization available for:” and then list the customization options that are low-to-no-risk (thinking things like accent colors, font sizes) - but totally block off options that are more likely to break things (not sure exactly what they’d be, maybe like adding extra panels, any non-stock add-ons, etc.?)

  • “Plasma Custom Workflow and Theming” - wide-open, go ahead and install some cursed program that rewires all of Plasma to look like the spawn of Windows Vista and the QuickTime 4 Player - it’s your PC! - but that comes with the caveats that “You have total flexibility to install system components that alter the basic functionality and design of your desktop. If you do so, you’ll have created something that hasn’t been tested by the KDE developer community (because it hadn’t existed until you dreamed it up!), so proceed at your own risk!”

And aside from “system stability” concerns, maybe there is a side benefit that if someone chooses the curated Plasma Standard Workflow, some of the potentially overwhelming numbers of options/choices that folks see in menus/settings that relate to alternative workflows just get hidden away?

Total pie-in-the-sky, I know, and maybe not even needed if - to your point - people breaking things with custom configs isn’t really a challenge for a significant % of overall users.

(Case in point, it wasn’t customization that threw me off with KDE Plasma, it was mostly Nvidia+Wayland glitches that I couldn’t figure out on my particular device - maybe in the food analogy used in the blog post, that would be “I only have a spoon, and the food that’s available here is sausage links, so I should probably find something else”)

1 Like

Cases where things just don’t work due to hardware or ecosystem issues are tough, and NVIDIA is one of the hardest ones.

Thankfully with Explicit Sync merged today, hopefully a lot will improve soon on that front. But it’ll surely be another thing in the future.

Maybe we could warn users in the live session if their system currently has any hardware that’s known to not be that well supported so they can make an informed choice.

But it’s tough to imagine what we should say. “It looks like you have an NVIDIA GPU; you might have a bad experience so consider using GNOME instead” is surely not the message we want to convey!" :laughing:

1 Like

The thing is that most people are somewhat familiar with food, they have some idea of how to make food and how much effort it takes to make it, how much ingredients costs and what can reasonably be expected of food and of food in a place like that. That’s not true for software.

In a soup kitchen-esque project, like food not bombs for example, it’s extremely easy to go from person who eats there to person who cooks there and the group of people cooking there may vary every time you visist. Even people who aren’t talented chefs can wash and cut veggies. It’s much more of a communal thing, as in the people making the food and the people eating the food are broadly the same community. In FOSS, while of course there’s also a goal to get people involved, it’s not that easy. Even the non coding work, like bug triaging, requires (compared to cutting a carrot) a lot of knowledge that most people probably don’t have. There’s a much clearer distinction and a bigger hurdle to cross over between users and developers. So the KDE developer community is a lot less equivalent to the KDE userbase.

It’s also easier to communicate why, for example, the food is vegan only (apart from the general ethical arguments for veganism). When we only have the resources to make one meal and our goal is to feed people, then it should be something everyone can eat. I think every at least somewhat reasonable person understands that. Whereas it’s not as transparent to someone who can’t code why feature 5789 can’t have a setting exposed to the user to configure it in 1.2 million different ways.

People don’t know how the thing works, so they have no idea how much effort doing x, y or z requires, so it’s more difficult to put a value to it or have reasonable expectations of it. I guess that’s why expensive watches let you see the mechanism, so that even though you still don’t understand how exactly it works and you couldn’t build a clock of your own, you see how much is going on below the surface to make every seemingly simple operation possible. While of course FOSS is also an open mechanism, I don’t think many people have looked at the source code and even when they do, they can only see static text that they don’t understand, they can’t see it running like one would see a clockwork.

The only solution I see is mostly not in KDE’s hands and also very much a long term thing: teaching people how to code, at least a little bit. Make it as much of an every person’s skill as cutting a carrot.


Some words from a total outsider: you find this attitude problem anywhere you go. I’m a volunteer fire fighter. If I get woken by my alarm in the middle of the night and I jump out of bed, race to the fire department, get dressed, drive the truck to the people with a flooded basement and pump the water out with my friends, I will often hear complaints that there are still some puddles left or that now there is mud from our boots on the floor. If I answer that I don’t get any money for what I do and that I go to practise once a week and even partly pay for my truck license and safety equipment myself, I hear “well you don’t have to do it if you don’t like it”.

That’s just how some people are. Others will make you coffee and drop a case of beer off the next day and I try to appreciate those and forget about the other ones.

BTW: I switched to Plasma as my DE only a few weeks ago (came from Cinnamon) and have to say not one day goes by when I’m not in marvel about the polishedness and attention to detail I encounter. Not only graphically but functionally. It’s a little like in the old days when I switched from Windows to the Mac.

I very much appreciate that and hope it stays that way for a long time. Don’t let the haters discourage you. The world is a better place because of your contributions.


It is a simplistic fable that ends in a joke. But, yeah, reality is much more nuanced and your analogy is a great illustration of another aspect of the relationship between FLOSS users and FLOSS providers. Pile on enough analogies and we’ll have an accurate picture of reality!

There is a point, though that I was trying to make, and that is that, although in proprietary software it is clear cut, the divide between users and creators of Free Software should not be a hard one.

Free Software communities should be as open and as porous as possible, to encourage collaboration from the public. The public should become the community, in fact. The people on the “user” end of the spectrum should feel as responsible and owners of the software as the creators.

So in this post’s analogy, sure, you can just grab a dish and eat it, or you can make your own dish, or help one of the cooks passing them ingredients, or washing up after them, or whatever. Anyone can participate to a degree. That is a possibility open to all.

You may have noticed that many people often perceive KDE (and other FLOSS communities) like for-profit software providers, like Microsoft, Adobe or Oracle; like an organisation that pumps out products ready to be consumed. This leads to misinterpreting the roles and confusing and frustrating interactions


As a devops who likes his systems to be comprehensible and maintenable, I am in favor of KISS. If it’s too complicated to implemented or maintained or even both, then it should be discarded. As Gnome is probably too much Simple and stupid and KDE is probable not enough, there is probably a middle ground where you can have a decent amount of features without too much headaches during code review.

Perhaps we can go soup kitchen style and say, “It looks like you want something that has not been completed yet; consider becoming a dev :wink::wink:”

The issue is what @eeeeeeeeee brought up: the barrier to entry for programming and even other technical non-programming tasks is vastly higher than the barrier to entry for helping to prepare food.

My 7 year-old already helps us cook, but she sees me working on KDE all day and she wants to volunteer for KDE too, and it’s like, “sorry honey, but…”


This is not right at all, users’ feedback is actually the most important factor for the success of any product, without users your product has no value even if it’s perfect, and you will certainly lose the future direction of its development.

Many projects open source themselves to get more feedback from wide range of users and devs, because their internal stuffs are not good to satisfy/attract the end users or fail to come with new ideas for the near future. Some businesses even implement dedicated services to get that valuable users’ feedback.

From what I see inside Plasma, users played and still are playing a big hidden role to report, demand and criticize what is changed, added or removed, they indirectly guide the whole process, without them the whole project would follow what only devs want, which proved to be fatal and dangerous for some known and big projects.

I think you’re misunderstanding what David wrote. He’s saying that people expect every feature we add to work perfectly, and when it doesn’t, they feel let down by it and may complain publicly.

Obviously we pay a great deal of attention to this kind of user feedback. But the point is that shipping buggy stuff that makes people complain is preventable. To a certain extent, we can reduce negative feedback by improving the quality of our offerings.

Of course, accomplishing that is the real trick. :slight_smile:


Sorry, I misunderstood him.

Concerning the high number of reported bugs, I think it’s good to know they are reported by real users, and they exist.

Personally, when I see a low number of reported bugs in any big project, I automatically assume the project has small users’ base, which can be a sign of a dying project.

And Plasma team did really a great job when Plasma 6 was released, they responded to many bugs and fixed them, so I think the project health is excellent with that intensive interaction between devs and users.


This is exactly how GNOME works. The “standard” GNOME Shell is way more static and simpler than Plasma, while “custom” extensions can change the UI in much deeper (and more fragile) ways than Plasma widgets.

Plasma kind of sits in the middle of the two options.