A remote code execution vulnerability in qmail

There is always an impedance mismatch between the users of the software and the developers. There is often a further impedance mismatch between power users and all other users, but let's ignore that for the sake of simplicity. For developers, maintainability is a Big Deal. Avoiding regressions is important, but sometimes, old code can be sufficiently convoluted or messy as to present an actual hazard to the long-term viability of the project. This may be because nobody understands how it works, because it is written in a non-extensible fashion, or because it's a pile of ugly hacks, but whatever the reason, it inevitably becomes a question of time and effort: How difficult will it be to exactly replicate the behavior of this bad code with good code? How strongly do we care about supporting this use case? How do those two concerns balance against each other?

But from the users' perspective, this is all invisible. All they can see is "It used to work, now it doesn't, why did you give me a pony then shoot it?" Of course, the average(!) user does not care that there is an actual answer to that question, because the average(!) user is not in a position to understand said answer anyway. Really, they either want to convince the developers to change their minds, or they just want to vent. The problem is that developer time is not infinitely fungible, especially in an OSS context. If literally no one wants to work on replacing the bad code with good code, then a replacement will not happen. In the meantime, other work is blocked on the bad code's continued existence. So what the user is really asking for is the project's cessation, which the developers obviously regard as unreasonable. In bad cases, developers and users will then proceed to talk past each other and get into huge flame wars on the project's mailing list, accomplishing exactly nothing.

(This is also where the second impedance mismatch comes in: Developers often choose to prioritize the needs of the many over the needs of the few, but in practice, power users are "the few." So they get frustrated when developers kill their prized feature in favor of supporting something more basic: https://xkcd.com/619/)

Instead, I think it's more helpful to focus on the respect with which users and developers treat one another. If the developers take a conciliatory "We're sorry this breaks your workflow, here are our suggested workarounds" attitude, users are likely to be a lot more accepting than if developers say "Your workflow is bad and you should feel bad." A little bit of compassion goes a very long way, even if it makes no difference in the actual software as-shipped.

And I agree, one should probably just remove the setting for full hinting.

It's clearly a regression if it's an unintended change. If dropping support for feature X is on the roadmap (for whatever reasons) then, well, not so clear anymore.

> Telling "we're not going back to the old behaviour because so and so" can at least tell where the decision is coming from. Telling "we're sorry it's going to break some setups which have such and such settings" at least acknowledges that there are problems.

Seems that in this case the maintainer(s) have quite clearly communicated what the path forward is, taking into account their priorities and available resources.

Disagreeing on the roadmap is fine, of course. But ultimately it boils down to

1. DIY.
2. Pay someone else to do it.
3. Convince the maintainers to do it.
4. Get used to the new way of doing things and move on.

Needless to say, throwing bile at the maintainers is unlikely to be a successful strategy for #3. Of course, maintainers should keep their cool and not be provoked (which, to an extent seems to have failed here), but OTOH maintainers, even ones who are employed by big evil soulless corporations, are humans too.

> In other words, if you're not a better programmer than the author, you're little people and your feedback is of no consequence.

Of course not. I'm sure all projects warmly welcome respectful feedback. Throwing tantrums and harassing maintainers is, OTOH, not likely to be a productive approach to getting what you want.

> It's almost like telling that you cannot say the restaurant food is foul because you're not a chef yourself and don't work in the same kitchen.

This case seems more to be like the customer going to the restaurant kitchen yelling that before the current owner took over and remodeled the place to be this posh restaurant, this used to be Old Joe's Biker Bar and they served proper food. And then they just continue yelling and won't leave until the owner threatens to call the police.

> It's almost like telling that you cannot say the restaurant food is foul because you're not a chef yourself and don't work in the same kitchen.
You do realize that you pay for the food in a restaurant, right? A more appropriate comparison would be a beggar who is given some free food and who then complains because it's just a slice of pizza rather than caviar and champagne.