July 01, 2008 01:11 AM by Ethan Blanton
While you probably can't call the Pidgin developers wild-eyed radicals (heck, a fair number of us don't use any software projects started after about 1998 with any regularity), we do have the tendency, from time to time, to shake up the Pidgin UI in a quest for improvement. Unfortunately, these genuine quests for improvement are almost always accompanied by a rich cacophony of "I hate the new <whatever>!". There are also often responses which are more useful and coherent, but this article is not about those responses.
Our standard response to such exclamations is to ask the user to specify what, in particular, they liked about the old behavior and don't like about the new behavior, and why. This seems pretty reasonable to us, but often it elicits responses like "I just like what I like", or "why should I have to justify my tastes?". Unfortunately, such responses are far more common than one might expect. The problem with this sort of attitude is that it nearly completely precludes any possibility of actual progress, and largely just so that the user in question does not have to give back to the community which provided Pidgin for their use in the first place.
Not everyone is a programmer, and we know that. Another standard response (and, again, a reasonable one) is indeed "patches welcome", but we realize and respect that not every user is prepared to take us up on that offer. For those who aren't, describing how changes to Pidgin have affected work flow and usability in some level of detail is a great way to give back to an open source community. Such feedback allows us to learn from our mistakes (as well as our successes) and improve our "product" -- and in a way which is just about guaranteed to be positive for the user taking the time to help out! Of course, we cannot promise to accommodate every work flow or implement every user's favorite feature, but we certainly can take those work flows and features we are aware of into account as we move forward.
Often, while we as Pidgin developers and contributors are engaged in trying to fix behaviors which have proven to be unpopular, users will request (a term which I use as a euphemism, as "demand" is normally more accurate) that an option be added to Pidgin which allows both the new and old behaviors as alternates. Leaving aside the fact that often the new behavior really is broken, and needs to be fixed regardless, this is a disingenuous suggestion. In a recent (on-going, at the time of this writing) debate regarding changes in the behavior of input area sizing on IM windows, I wrote an email which said the following about this:
Options are expensive.
Each individual option may be simple or trivial, but they add up. Options to do with UI behavior are particularly expensive, due to their frequent interactions with the vagaries of UI toolkit behaviors, etc.
This expense takes the form, mostly, of subtle bugs and extra programmer effort. We have had numerous examples of options which appear to be simple on the surface causing numerous bugs and undesirable behaviors. A recent and memorable example of this was the option for persistent conversations -- I think we all agree that the ability to have conversations "open" without an open window is one which is appreciated by many users, but this seemingly simple feature has caused quite an avalanche of small and not-so-small bugs. In fact, there is speculation that the one pixel high input area which some people are seeing stems from this very option.
Anyone who tells you that options are not expensive is either not a programmer, or has never worked on a large program. It is true that orthogonal options in a clean code base can be implemented with little cost in many circumstances, but even the most forward-thinking and competent programmers will be blind-sided by subtle interactions on occasion, especially when throwing third-party libraries and code into the mix.
So, if options are an avenue of last resort, we're left with three other immediate choices in the face of an unpopular (honestly, usually this means "unpopular to a minority", but try convincing a FOSS user holding a minority opinion that he or she does not represent the Gospel truth, some time) development decision: revert the change to previous behavior, keep the new behavior unchanged, or figure out what is wrong with the change and forge an even better solution which satisfies all parties. Again, from the email previously quoted, I said the following on this subject:
Progress is good.
The question is not whether Pidgin can remain exactly the same forever (it obviously can), but whether we want it to. This should be particularly understandable in the world of open source software, where people consider a project which has not released in as little as a few months "abandoned" and ripe for discard. We want to make Pidgin better, we want to make it easier to use, and we want to make it more pleasant to use. This means that statements like "I want the old behavior back", with no justification, are not useful to us. On the other hand, explaining WHY you want the old behavior back, and what precisely it is about the old behavior which makes Pidgin better and more useful to you, allows us to improve our software. It may be (as many users have found in the past) that the old behavior isn't really what you want, it simply afforded some particular functionality which the new behavior has lost. If that functionality can be identified, we might even be able to provide it in a superior way which you find more pleasant and useful to use.
The feature currently under debate is a great example of this. We have had a couple of users who have explained why they need large input areas, and the circumstances under which this functionality is useful to them. We have more or less agreed (I believe) that the new behavior is not sufficient for all use cases, and we do intend to improve it. Using the "why" we have heard from some users, we will hopefully be able to do so in a way which cleanly adds the new functionality while preserving their requirements.
Reverting to old behavior should be seen as a last-ditch effort which is giving up on an attempt to make Pidgin better. It might be the right choice, but the change was made for a reason -- in this case, many people like and want input areas which automatically resize. Numerous iChat and Adium users, for example, have specifically asked about this behavior in the past.
So there it is; we want to avoid options except where options are truly the right choice, and we want to be able to make progress in improving Pidgin, even when those improvements cause behavior to depart from previously established norms in significant ways. In order to accomplish this, we need help -- as Pidgin developers, we use Pidgin in only a limited number of work flows and situations. Input from users with differing habits and expectations gives us a broader perspective, and allows us to improve Pidgin for everyone. A lot of our best ideas and UI changes over the years have been inspired by comments by users, comparisons to other IM clients or software packages, and even third-party contributions in the form of patches or code.
All pleas to the betterment of Pidgin aside, defending assertions of goodness and badness is simply the right thing to do. Beyond even that, it is a reasonable bar for developers to apply to users when judging whether their opinions and commentary are worthy of time and effort. While it is true, as discussed above, that not all software users are software programmers, all software users should, with some application of effort, be able to express their opinions about features and changes in a clear and logical fashion. While some Free Software users seem to think that their right to use and modify software extends to a right to have software modified for them (we have taken to calling this Free Software User Entitlement Syndrome), the fact of the matter is that Free Software is a privilege, not a right. (Lest anyone become upset with this, note that I do not mean that the rights granted by, e.g., the GNU Copyleft are not rights; bear with me.) This is because that software must be created by someone, and that someone has every right to create the software they wish to create. Once that software is created and released, every Free Software user has the right to use it in all of the glory allowed and guaranteed by its licensing, but the choice to create rests with those who have the ability and inclination. Not surprisingly, those with the ability and inclination to create Free Software may choose to spend their valuable time assisting users who give back. This is not only more rewarding than helping users who issue nothing but demands, but it seems (at least to me, and to some other Free Software developers) to produce a better product. Changes made with an eye to existing and articulated use cases are guaranteed to help at least the person who articulated the use case, for example.
Consider the issue to be similar to democracy. If you didn't vote in the election, you can't complain about the results. If you are unwilling to provide useful input to the developers of the software you use, then you forfeit any right to ask for changes. The difference between useful input and an impudent demand is nothing but justification, clear explanations, and logical argument. This is not to say that every FOSS developer you approach is beholden to implement any suggestion which you take the time to defend, but said developer certainly can be expected to at least consider your suggestion fairly if you put in some effort. Remember, at the end of the day, it is the developers' sweat and effort that go into the software, so the buck stops there.
Help us help you
July 01, 2008 01:11 AM by Ethan Blanton