[Pidgin] #4986: automatic chat input field resizing should be optional, regression from 2.3

[Pidgin]

#4986: automatic chat input field resizing should be optional, regression from 2.3
---------------------------+------------------------------------------------
  Reporter:  swbrown       |       Owner:                   
      Type:  enhancement   |      Status:  closed           
  Priority:  minor         |   Milestone:                   
 Component:  pidgin (gtk)  |     Version:  2.4.0            
Resolution:  wontfix       |    Keywords:  chat input resize
   Pending:  0             |  
---------------------------+------------------------------------------------
Comment (by DanLivingston):

 Well, let me first thank everyone for contributing their feedback to this
 tracking ticket.

 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 object."

 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 GAIM?

 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.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/4986#comment:272>
Pidgin <http://pidgin.im>
Pidgin