[This article translated in a latter time]Originally published in July 9,2008[EDIT - oct 20 2008: this article is quite old, but seems to have grasped well some AROS recent ongoings so give it a read]
Unless somebody else of the Cannocchiale bloggers don't tell me how to recover my old unpublished articles (waiting for time, inspiration, further documentation,etc.) i feel kinda forced to start again this article, with the needed updates.First of all, let me introduce the "causus belli": Pidgin Bug Report, an article on Product Beautiful and a further Article on Product Beautiful on the subject.The outcome is surely known on who is following open source software progress: since last jannuary pidgin users are complaining about a new feature that resizes automatically the message textfield; the developers answered that it was introduced by them because they liked it and they have no plan to remove it or make it facoltative. A big discussion arised, quite polite but with strong opinions and brought to a riot against developer's decision, at the bug report closure as "wont_fix" and at a fork of the program, funpidgin.Among all the interventions, one quite interesting from Dan Livingston, teacher of "collaboration in the Open Source world" in a North American college, going quite hard on developers behaviour:
I teach "Collaboration in an Open Source World" at a local college. I
have been searching for, and in this ticket have found, a perfect
example where communication between open source developers and users
fails at multiple, fundamental levels.
Obviously, the motivations of open source developers are varied;
some do it for technical enjoyment, others enjoy knowing they are
contributing intellectual capital to a better world. The problem is
when the motivations of open source developers conflict with the
expectations of users.
Consider every wildly successful open source project: the users are
enthralled with their ability to perform new activities in ways
previously unimagined. Rabid dedication grows, and an evangelical fan
base results. Pretty soon, it's obvious why users would not want to go with non-open source software alternatives.
What happens when those same newfound powers are taken away? What
happens when the developers impose their personal dogmas upon the
project? Even for as small an issue as chat window resizing, a minority
(or majority) of users will emphatically express dissent.
It's easy to see why open source developers could develop dogmas.
Some like to fantasize about the theoretical limits to which a design
may become "pure", developing a vile repulsion to anything which steers
away from purity. Others become obsessed with metrics such as
maintenance effort per line of code, even though they often worry about
features and lines of code which only contribute to 1% of the
complexity of the application. Yet others develop fixation on "ultimate
user simplicity", feeling that two options are better than five options
which deliver more power. The most dangerous dogma is the one exhibited
here: the God feature. "One technological solution can meet every
possible user-desired variation of a feature."
The initial lure of open source software is that quality software
should resoundingly meet the needs of users. As demonstrated up until
Pidgin 2.4, the fan base has emphatically been extolling the virtues of
Pidgin. But when developers take a feature away, presumably to
implement a "better version", and that better version in fact is a step
backwards from the functionality previously available, they had better
have a damn good reason. Such a reason is lacking here.
"This is how IM should be used." "Our design is better." "We will
only consider a 'pure' design in which we can accomplish the old
functionality in a paradigm that also supports the new functionality."
"An additional checkbox is too detrimental to the user interface."
"Maintaining two branches of logic within the dialog sizing component
will be untenable." "We have no interest in not pushing our shiny new
These are all statements, which if executed within a corporate
arena, would get developers fired. Developers, make note: you are doing
a disservice to the community you claim to represent, and are doing so
with false illusions that you are "right" because you have convictions
in your justifications.
It does not matter that you are open source developers with the
autonomy to ignore your user base. It does not matter that a plugin
"could" be developed to solve the problem. It does not matter that you
feel your default solution is superior. It does not matter that you
only want to consider solutions which can be implemented through the
new solution framework. It does not matter that your users should
abandon your product if they don't like it. It does not matter that
someone could fork the code base. It does not matter if 11 thousand
people download your source code per day, and only 270 complain about
it. For each of these, there are very valid rebuttals.
So, only 270 complaints for this feature, out of 11 thousand
downloads? How many people immediately uninstalled the program when
they realized it could not longer do the simplest functionality that
GAIM and other IM agents do? How many don't know that they are using
software that is now crippled in comparison to its former flexibility?
How many use the software today, but will switch to GAIM tomorrow when
they hear from their friends that it's so much easier to resize in
The fact is that typing letters into an IM window is THE most
critical task of an IM program. Users have varying needs, needs which
can not be addressed by your limited attempts to come up with "one
solution for everything" that incorporates "shiny new logic" that
demonstrates how smart you are. You are ignoring the fan base with a
dedication to your convictions that is alarmingly evident to even the
most unobservant of followers, and as such, you are demonstrating that
you no longer deserve to be in the position of servicing the needs of
your user base.
For the sake of everyone involved, I hope you find your path back to the light.