If we do our job right, if we continue to improve in the right ways, the need to know what protocol you reached me on will only decrease with time, from its already low level. For this reason, we feel that having a graphic in the buddy list to tell you which protocol a given contact is using right now really is not all that important. In fact, it is at times downright confusing. We came to that conclusion after years of walking users through things, and after years of requests that we mimic other clients that have already removed that bit of information from their buddy lists.
I fully expect that the debate will not end here, even though we did create an option, in 2.2.0, to show the protocol icons again. Some users will persist in trying to hide from you on yahoo, but not on AIM, or will want to let a friend sign on for one evening without pointing Pidgin at a new config directory.
What is the most common praise?
We get praised for many of the things that we are most actively criticized for. Again, this really goes back to the disconnect I mentioned at the beginning. Those complaining are clearly not looking at the same population that we are. Their insistence that they know our user base better than we do is one of the most mind-boggling things I encounter in my work on Pidgin.
Even if you know 100 other Pidgin users, and even if they all agree with you, you know a tiny little fraction of our user base, and I can find another group out there somewhere that will hold an opposite opinion.
One of the places this reality comes across most clearly is when looking at encodings. A number of the protocols have exceptionally poor support for international users. On top of this, detecting what encoding a message is being sent to us in is a VERY hard problem, one that most clients do not even attempt to solve. One of the more frequent requests we get is that we assume that anything that isn't Unicode must be iso-8859-1, the most common encoding for Western European languages.
Ironically, even though Europeans are typically credited with being far more sensitive about cultural issues, they are the ones most frequently requesting this. The problem of course is that this encoding is very unlikely to be the right choice for anyone in Asia, the Middle East, or Africa. We have consistently refused to make such a decision, instead requiring users to enter in the encoding they want us to fall back to.
I cannot count the number of times I have been told that "everyone" uses iso-8859-1 (Americans typically do not care. 99 percent of the text they send fits in plain old ASCII). Yet for each such user, I can guarantee you there is someone in ASIA who would hate that choice.
What strategies do you, as a development team, use to cope with the challenges of taking every one's views, complaints and suggestions into account?
All of our development happens out in the open. We spent six months discussing different ways to handle status on an open, public mailing list before the first 2.0.0 beta. Even so, after releasing beta1 and hearing the feedback, we made non-trivial changes. Users persist though in insisting that we cannot have spent all that much time thinking about it, or we "obviously" would have come up with something different. Their proposals, varied as they are, have never come up with something we did not consider either in that six-month period, or in the time between beta1 and beta2. Yet they still complain.
At the end of the day, we listen to everyone. We argue with some people. We argue quite frequently amongst ourselves. And then we come to a decision, and after that we raise the bar on what it takes to change that decision. You have to come up with something we didn't consider before.
We will NEVER make a client that will please everyone. So we do not try. We are aiming to write something we want to use first, and that those we personally know want to use second. Historically, as I have said, this has resulted in pleasing most, but not all, of those who now make up our user base. I see no reason to think that will change.