The article has one valid example of a bug. If it's a bug in the application, writing an open letter about it is not helpful. If it's a bug in the theme, the application developer is just not responsible for it.

If you clicked through to the blog post linked in the article, you'd see more examples. https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-a...

>If it's a bug in the theme, the application developer is just not responsible for it.

And how many times would they have to tell the end user who opened an issue on their app's tracker that?

> And how many times would they have to tell the end user who opened an issue on their app's tracker that?

I'm afraid there is no way around that issue with free software.

In this case the author is suggesting a way to avoid it, for distributions to not theme and introduce the bugs in the first place.

for distributions to not theme all third party applications by default, and for that to be a per-app user toggle.

> And how many times would they have to tell the end user who opened an issue on their app's tracker that?

There's a super clever life hack my wife used when working in e-commerce. She kept a text file with prepared replies to most common issues and questions, and used the OS's built-in copy-paste functionality to quickly responding to messages asking about the same thing. I hear this kind of functionality is even supported directly in desktop e-mail clients these days.

Have you actually written and supported an app before because that's not how it works.

The users always blame the app. And then when they can't get the app to work they stop using it.

Which means the developer just lost a potential customer.

I did, and you don't have these "customers" if distros don't ship your app. So you're most probably still net positive even if distros mod your app.

If you don't like people modifying your software, don't publish it under permissive license.

Unfortunately, this is ultimately the problem with free software. Either you publish with zero support, and users end up using your software badly (via poor blog posts telling them what to do) or they don't use it at all; or you end up paying for your contribution to the world with even more of your time, supporting people who either don't realise that they've introduced the faults themselves (either directly through their own errors, or indirectly through their choice of distribution or guide they've followed).

How do you solve the social problem of a large majority who feel entitled to everything for free?

My solution was to give up, publish free stuff anonymously with zero support, and charge for anything I actually care about. My charged-for software has multiple orders of magnitude more users than the free software, and effectively funds the free software that nobody actually uses.

I regularly think about not publishing the free stuff anymore, but I figure that even if a single person benefits from it, it's a net-positive, and so I keep going. It doesn't stop it being incredibly demoralising.

> Unfortunately, this is ultimately the problem with free software. Either you publish with zero support, and users end up using your software badly (via poor blog posts telling them what to do) or they don't use it at all;

You can have it on a website where users can talk to other users. And if you like, you can chime in. Say some code sharing platform. My experience is that people will help each other out usefully. You can even nudge them in this direction.

> How do you solve the social problem of a large majority who feel entitled to everything for free?

You don't. Why would you? You don't need to react to what you judge being an entitlement. You can misjudge though.

I've had reactions when contributing bug reports that I felt other person thought of me as being entitled, after I've spent considerable time identifying the root issue and suggesting a code change.

I've also thought of someone being entitled initially, when in the end the person ended up contributing useful service to other users of my program.

> The article had pretty clear examples of where theming went wrong.

“It's possible to do X wrong” is insufficient to support “You should not do X”.