Slashdot Mirror
Pidgin Controversy Triggers Fork
paleshadows writes "Pidgin, the premier multi-protocol
instant messaging client, has been forked. This is the result of a heated, emotional, and
very interesting debate over a controversial new feature: As of
version 2.4, the ability to manually resize the text input area has
been removed; instead, it automatically resizes depending on how much
is typed. It turns out that this feature, along with the uncompromising
unwillingness of the developers to provide an option to turn it off,
annoys the bejesus of very many users.
One
comment made by a Professor that teaches "Collaboration in an Open
Source World" argued that 'It's easy to see why open source developers could develop dogmas. [...]
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." [...]
You [the developers] 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.'" Does anyone besides me find this utterly ridiculous?
Just can't get our act together. It's why we've never been able to get past our image as disorganized and in general lower than the other birds.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
This whole situation reeks of some crusty developer stuck in his ways.
If there's no technical reason not to allow both options with a simple option in a menu somewhere, then yes it is ridiculous. If there is some downside to allowing users to resize the text input area then a fork is exactly what is needed. Open source is awesome.
"A witty saying proves nothing." - Voltaire
More options are always better, right?
I mean, sure, forking a project means that we now have fewer developers concentrating on a product than before, but it's for the best because now we'll have two IM clients that are nearly identical except for some minor things. All because some programmers are egotistical assholes!
The Open Source world needs to grow the fuck up. More options aren't always better - more good options are better, more options for the sake of having more options or because you can't learn to play nicely with the other kids are stupid.
I know some will probably tag this as a troll or a flamebait, however IMHO this is exactly why Linux will never be able to really replace either Windows or Mac OS X for desktop usage.
Too many people who think they know better than the end-users, and too much work being done by lots of people on different, competing projects. You need to unite your efforts, not work against each others. This fork is just another proof (and WTH is with that "premier multi-protocol instant messaging client" remark? Nobody uses that on Windows and Mac OS X).
The whole KDE vs Gnome debate is one of the things that keeps Windows on PCs.
Posted as AC because of Linux and OSS zealots.
All too often on software projects, I see someone spend several days figuring out a neat thing to implement that they personally think is a great addition.
...
And when it comes time to remove it they defend it. They may even realize that they were wrong thinking everyone would love it. But they just don't want to give up that code that cost them so much time to figure out and write.
Coding for several days only to realize that you need to throw everything you wrote away is one of the hardest skills for a developer to learn
My work here is dung.
Add the following in Preferences window:
[X] Allow resizing of chat input area
-William Brendel
"Does anyone besides me find this utterly ridiculous?"
Depends on what you mean. Do I find it ridiculous that developers are ignoring a sizable portion of their userbase and implementing a feature that many people would like to disable? Yes, I find it ridiculous. Not terribly surprising, but ridiculous nonetheless.
Do I find it ridiculous that it's causing a project to fork? Not particularly. This is supposed to be the one of the greatest advantages of open source; if you don't like the way people play, you can pick up the pieces and start your own game. Silly me, I had secretly hoped that the threat of something like this happening would keep software like pidgin from ignoring its user base. Guess I was wrong.
...because their Trac is slashdotted. Problem solved.
here
Seems like something that would be done to a Gnome app. Hope that's just a coincidence. Back to Kopete I guess.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
This wouldn't be the first time the pidgeon folk have decided to change the interface and refused to let people keep things the way they liked. Forks have been threatened before over their decision to hide protocol icons as well. I'm glad they separated the gui from the rest of the program - both this and the protocol icon decision really bug me.
For every problem, there is at least one solution that is simple, neat, and wrong.
MS would might have just made it an option.. doesn't sound like it would have been difficult to do. This issue has been brought on by the users anyway, MS users don't have the option to fork off a new codebase, they just have to take it up the ass with whatever MS does (I'm thinking of Office here mainly, where you just don't have many viable alternatives because of the attitude of the world that Office is the only thing you can use to write letters or make presentations and spreadsheets)
which is totally what she said
A writing professor once called this "murdering your darlings," in the context of writing fiction.
You develop a scene with blood, sweat and tears, and then realize it's baggage and there's a better way, and shorter/more compact is always better.
It hurts but it beats the alternative, which is reduced quality of writing.
technical writing / development
For anyone interested, the fork is called "Funpidgin" and can be found here.
The summary makes light of it, but the Funpidgin page explains that their intention is to respond more directly to the requests of the user community. In addition to the feature mentioned in the summary, Funpidgin has implemented some others, and will presumably continue adding user-requested features (while still integrating upgrades from the pidgin codebase, presumably).
Forks are both good and bad; this one is no exception. On the one hand it "wastes effort" and can duplicate work. On the other hand, it can give the user community (which isn't homogeneous) the product(s) they want. It can encourage useful competition. Often the end result will be better than if no fork had occurred. Another example is the Compiz/Beryl fork, which created some duplication for awhile, but ultimately turned out for the best since the merged Compiz Fusion includes the best features from both (a stable core and all the whiz-bang features users wanted, in the form of plugins).
If both the Pidgin and Funpidgin developers work to provide something that their respective users find worthwhile, then what's the problem?
Considering my general hatred of the Pidgin UI, no, I don't find this ridiculous.
Let's start with Pidgin's UI Sucks, which details some of the weird UI decisions made back around version 2.1. Fortunately they've fixed almost all the issues listed in that post.
More Pidgin Bashing is just a bug, so let's skip ahead to Pidgin's Crappy Formatting Icons which they have not fixed.
If I ever had the time to, I'd like to write a new UI for libpurple, Pidgin's backend. I have some ideas - but not enough time to actually learn how to use libpurple.
Maybe I can help with this fork, called... uh. Hm. The summary doesn't appear to mention it.
Ah, here we go: funpidgin.
You are in a maze of twisty little relative jumps, all alike.
Ya know, I can't blame the community for this fork. The gaim/pidgin developers have had a bad history of 'God complex'. Hell, just recently they refused to make any changes to the way Pidgin handles SASL authentication to XMPP servers due to a change in the 2.4 codebase that completely breaks SSL encryption to the OpenFire XMPP server, whereas the 2.3 codebase AND every other XMPP client seems to not have any issues. Their response was something along the lines of "yeah, well we're doing it right..every other client is doing it wrong". I find that hard to believe. This ultimately leaves me with 2 options: either don't upgrade past version 2.3 of Pidgin, or use another client. And yes, not being able to resize the input text box drives me absolutely crazy. I look forward to a forked version addressing this and the XMPP SASL authentication issues.
I think we ought to formulate the Slashdot law, in a similar spirit to Godwin's law:
Slashdot Law: As a conversation on Slashdot grows longer, the probability of comparing someone to or bashing Microsoft approaches 1.
"What lies behind us, and what lies before us are tiny matters compared to what lies within us." Ralph Waldo Emerson
here
I think the main reason to not make it an option is because it is such a tiny obscure detail that you wouldn't even think to look for an option in the first place. And thus adding the option to the GUI would be useless clutter. Good usability is often about removing options and make things behave the right way at default.
Just staying AC
But, yeah it's no joke... I gave up on being a test engineer for software after being let go (along with some others) at M.S. because I a would not pass a product with a clearly significant usability flaw. The development said it was by design and a feature. (Very similiar to the resizing functions mentioned above.)
I went and did the numbers and a full quality project, VOC data, etc. I presented my case at a later build. The developer, not having any actual evidence but his opinion, went into a flame war, trying to take me down. Effectively, I was insulting is 'intellegence' and want to 'undo months of work'. When that failed, he called me racist. He won, I got let go. I found out he was let go a couple months later over trying to defend the same 'feature' after a presentation with some higher ups, and insulted someone above him.
These flame wars happen all to much, I've found many programmers have 'control issues', perhaps that's what makes them good programmers; but lousy decision makers.
The difference with Open Source and other groups of talented, opinionated, and driven technical groups is that with OSS the "discussions" are held in mostly public forums.
Yes, and no.
The thing with this sort of program is that it'd be trivial to put a "choose your own color" option in the configuration, so everyone could make the bikeshed whatever goddamn color they wanted.
Instead, the dev team has hashed this whole thing out amongst themselves in a "bikeshed" style debate, and they've come up with this fricking solution which they had to sweat blood to get everyone to agree to, and then it turns out that users don't like it?
I can see why they're stuck on their solution, but I CANNOT understand why they don't understand that extra UI options are critical to a good app. Forcing users to deal with a UI that cannot be configured at all is not the way it goes in todays programming.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
rather:
No slashdot thread is complete without at least one (1) Microsoft bash.
Corollary: As it adds to the completeness of the thread, it will be modded informative.
"The cup is in turn designed for holding hot or cold liquids, and has an open rim and closed base." --US Patent #5425497
Well, in all honesty I don't think it's over the text area so much as the fact that those in charge are adamant about allowing anyone to configure the client as they see fit. This is just a small symptom; the underlying cause is unbridled arrogance and muleheaded stubbornness.
Tcha. Then make it a compile time option and let the people who feel that strongly about the issue enable or disable it at build time. The can stick the instructions in the FAQ.
I really can't see the point of refusing to budge over such a trivial issue.
Don't let THEM immanentize the Eschaton!
While I completely agree with your premise - that usability is often the opposite of allowing configurable options for everything - I think that the way they made the dialog behave is not the right way. I have never seen another application do what pidgin now does. In general, that doesn't necessarily make it the wrong thing to do but in this case I think it does.
I mean, pidgin supports plugins. Is there a reason this can't be implemented as a 'let me resize the input box' plugin?
I agree that simplicity is almost always better, but I would say that good usability is always about listening to user feedback. Basically this change flunked the usability test for a lot of folks and the developers should find a way to elegantly implement that option. There's undoubtedly a way to add this ability without adding "useless clutter." And I would say this clutter wouldn't be useless since people are asking for it.
This space intentionally left blank.
Options suck.
Every option means doubling the number of possible configurations - which makes proper testing of the application twice as hard. It also provides twice as many weird ways that the developers can have their apps configured that will prevent them from noticing issues as they personally develop.
There are some applications and configuration options where this isn't true - for example, a text editor for programmers would be less useful if you couldn't configure how many spaces are in a tab - but for simple end-user facing applications like Pidgin and the mechanism for resizing the text input box making a choice arbitrarily (or optimizing for UI simplicity) among the usable possibilities is probably the correct design decision.
There is always going to be a vocal minority who really wants to be able to configure every last little thing about their software. For free software, they can simply be pointed to the source code and told to have fun. As a usability compromise, features like Mozilla's "about:config" are good - as long as the user is told that weird configurations won't be supported. But in this particular case the best solution really seems to be for the Pidgin guys to just tell the forkers to "have fun" and then proceed to ignore them because the feature they're offering is silly and pointless.
-- The act of censorship is always worse than whatever is being censored. Always.
You are absolutely right if the project only ever has to support a single UI option. However, products that expect to be around for a few years accumulate dozens of such options. At this point, nobody has the bandwidth to test every possible configuration or fix bugs that only affect a few users who chose a particular combination. The code which is not used in default configuration is likely to not work properly with new core code, not be ported to additional platforms and plain look ugly with main UI which is skinned for a particular layout. Users who try the product on someone else's machine walk away with a negative impression as it has been customized to something that most people find unusable.
On the other hand, if you fix the UI, lots of users will complain initially. A majority of those will quickly adjust and stop noticing the difference. Some will walk away or fork the project. However, for those that stick around are much more likely to find that the UI functions properly in the manner intended than if the attention of developers was spread among thousands of possible configurations.
It's a basic choice for a project developer to do one thing well or provide many options where some or all do not work quite as well.
This has been well overdue in my honest opinion! From every minor release to release we have been seeing subtle UI changes that offer absolutely no choice. The preferences dialog hardly ever changes while other things are changing on me and I'm stuck with the changes.
How about the release where they changed the formatting button bar into two drop-down menus? I'm glad that you can actually revert it back to a useful formatting bar by right-clicking it and selecting the alternative. But the icon changes, the dropping of the emoticons from Gaim 1.5.x, and more things I just don't care to remember right now, I'm tired of it. This is precisely why I left GNOME for XFCE; I still wanted a GTK+ interface but I didn't want to see any more features stripped away from me and stupid UI/dialog box changes because "the last version is too hard for users." (Granted that excuse is not coming from the Pidgin devs.)
I believe my superior grievance lies with Pidgin devs' claim to investigate what gaim-vv attempted: adding support for webcams and/or microphones for the protocols that support it. They posted that this development would be considered after a stable 2.0 release. Well they've had Pidgin 2.0 release a long while back now, and do I see even a hint about what they said? Nope.
Seriously what are they thinking? I can only imagine that, if in their position, obviously Pidgin is (apparently) the most popular GTK+ based IM client. If it were up to me, I would work on expanding the client to support the other functionalities of the supported protocols that are still not implemented, such as the aforementioned audiovisual support and file-transfer support that actually works on protocols other than AIM's.
Not posting as AC because if this is worthy of bad karma than I deserve it. This had to be said. I welcome a fork that works on making progress instead of focusing on satisfying egotistical interface desires of the developers.
Gentoo Linux - Wouldn't have it any other way. And fuck beta.
While it is an annoying "feature" that the text box resizes, a better fight for devs to get into would be tackling larger aspects of the program... like making file transfers work, work reliably, in all protocols. Or perhaps adding webcam support or a plug-in for same.
Maybe this isn't really about the text box itself but the attitudes which arose from the suggestion of changing its behaviour.
Indeed. Being able to customize your interface to whatever you find most practical and useful is something I really appreciate, were available, and really miss, were it's lacking.
I would argue that there are many different ways to see, edit and input information; and some prefer one and others another. Giving people the ability to chose is definitively a good feature in any product.
The Long Now Foundation
I suggest everyone read this developers take on the issue. I think you will find it quite a bit more understanding than the original post makes it out to be.
I have never seen another application do what pidgin now does.
I have. Google Talk.
And I hate it. It drives me nuts, actually. I hate it so much I stopped using the "official" Google Talk client and switched to Pidgin.
Joke's on me.
Lack of planning on your part does not constitute an emergency on mine.
"You're reading this because our trac can't keep up with all the people clicking through slashdot. The ticket really isn't very interesting, it's mostly name-calling. You can read it later, when the flood of people fetching it is something trac can handle.
... yes, there are people who are unhappy with our IM client, which is a work in progress. Yes, a lot of the comments on the ticket were completely unreasonable. No, there are not a large number of unhappy users on the ticket, but there are a large number of comments. We call this a "vocal minority". Yes, we have already implemented most of the "features" in the fork -- some of them before it ever forked. No, we aren't running back to the old method of resizing the input box, but yes, options are still on the table.
In the mean time, here's a simplified summary of the situation (not the ticket).
Yes, there is a fork
This statement is not intended to be a position, it is simply a summary of the situation as we understand it.
Happy browsing. "
Always whining! "I want my software to do this!", "I want this feature!", "I don't like that design!".
If it wasn't for them, programming would be much easier.
And sometimes things have to be options. Look, clearly there's a class of users that finds the resizing feature to be useful -- which is why it was requested and added. At a guess, it's really nice on platforms with really small screens -- displaying a single line of input field lets you see as much conversation as possible, most of the time. So that's nifty.
However there's also a class of users that finds the whole thing stupid and annoying and inconsistent. For one, UI elements aren't expected to change their shape without an explicit request, and for the whole screen to jump while you're typing is pretty jarring. For another, thanks to the "options are evil" thing, there's no way to configure the minimum or maximum size of the input area, which leads to a UI that's just generally ugly when the app is used in a different way from how the developers are expecting. That's not friendly either.
So this is a case where configurability really would be simple, and worthwhile, and make everybody happy. But the pidgin developers have instead chosen to say "fuck you". And not for the first time either. They aren't the least bit interested in communicating with their users, and they haven't really been for years. In a sense, that's their right -- but it doesn't mean the users are required to put up with it. They say that they work on pidgin as a hobby activity, for their own satisfaction -- well let's see how much satisfaction they get from "owning" a project with no users.
Its important to remember though that with many options you increase the amount of testing an application requires. That might not be the case for this text entry box, but having an option of MDI or not is pretty significant. It would be easy for a developer to put in a feature that breaks the option he doesnt use and it becomes necessary for QA to do a full regression in both modes.
People love options, but they arent always whats best for a product. If you can come up with one option that makes 90% of users happy thats probably better than having a preference that doubles the amount of testing you have to do.
This case, however, seems like a good candidate for an option.
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
He talks about standard responses to UI complaints as if they are grudgingly listened to by developers and the "patches welcome" reply is generally used as an OSS way to tell users to go-climb-a-tree. Read the whole article.
Hopefully they'll use git so they can merge when they make up.
Getting the job done quickly?
We are talking about an instant messaging program here right? Something that is used for communication with others? Just like cell phones, or email clients. I judge them on how well they work for communication and how many other features I want/need.
For some people, the more options the better. I really prefer to have one device to carry around, not 3-4. Phone, email, mp3 player, mild web surfing, all in one, but just hacking together something that does all of this "quickly" isn't most important, as ease of use, size, cost, and extra options make all the difference.
I haven't followed this whole story, but this seems like a rather stupid argument to get into in the first place. Mandating some annoying resizing text box for all users? No thanks, I would stop using a program that mandated something that ridiculous. A feature? Sure, maybe some people will like it. But I also wouldn't use an IM client that didn't let me resize the chat input box either.
I had this same argument with Mac vs. Windows. Especially with that stupid one button, UNBELIEVABLY retarded ROUND mouse POS they came out with (sometimes you actually had to look at the damn mouse to figure out which way was up, so you could orient it correctly. One of the dumbest ideas ever for a computer mouse.)
At least in Windows, there are several intuitive ways to do the same action, so you don't need to learn the one or two ways the developer thought you should do it. You could right-click, use keyboard shortcuts, go to a menu, drag and drop, etc. For me, almost nothing in MacOS was intuitive, while I could always just figure out some way of doing what I needed to in Windows.
Basically, it comes down to: Any part of the GUI that is Non-Standard should be an option that could be turned on/off depending on the user's preference.
"Auto-Resizing text input box? This is the coolest thing ever, everybody must use this and know what a God I am for thinking of it and developing it, therefore it must be mandatory." -- Get over yourself.
Just because you're paranoid, it doesn't mean that they're not out to get you.
Or have they stopped removing features and options that are actually necessary yet?
That's an issue with maintainability though, not usability. The program can be just as usable with a compile time option in there. More so, since it doesn't annoy all those people who find the feature doesn't suit their work patterns.
And really, there's no reason it has to even be a maintenance issue with proper software design. The IM code is already isolated in libpurple, They could (if they wished) have a separate interface with no more side-effect issues than there are already between finch and pidgin. It would require that someone to commit to maintain the option, but then, given that there seem to be enough devs to support a fork, that probably wouldn't have been a problem.
Me neither, I must admit, and for the same reason. Still, I have to say that over the past five years I've gone from being an argent fan of Gaim to using Kopete and Amsn almost exclusively. So I'm not entirely surprised that their userbase is up in arms.
Don't let THEM immanentize the Eschaton!
I couldn't agree with you more. GAIM is superior to Pidgin for the reasons you mention. I tried to compile Pidgin once, and it requires that pile-of-crap GnuTLS that I couldn't get to compile for the life of me. OpenSSL, of course, works great. I use CenterIM now and couldn't be happier.
This is the "ego bigger than brains" mentality that permeates the open-source community and it pisses me off. This is the same mentality that resulted in Firefox/Thunderbird with their paucity of configuration options compared to Mozilla.
What? You mean I have to configure a "blahdeyblah.blah.blah.yippideedoodaa" parameter in an "advanced configuration" section? How the hell is that "easy-of-use". The old Mozilla provided me that parameter straight-away in a nice graphical dialog box.
Sorry, but some nerd-ass software developer (I include myself in this class of individual) doesn't know jack about UI design. That's right, I, myself, don't know jack about UI design. And neither do you, Joe Linux programmer! Let's listen to the users and make nice easy-to-use software with lots of well-organized options available.
I frequently exchange paragraph-long messages with my friends on IM. I frequently exchange code bits on IM with my colleagues. The Pidgin developers are ignorant idiots thinking that people only send "one-line messages" on IM. Who the hell are they to say that I can't exchange code bits with my colleagues? What's their IM username? I'll send them some source code one line at a time!
Alrighty then.
*ahem* Microsoft SUCK0RZ!!!1111ONE
There. Mission Accomplished!
Honestly, the best way to deal with it would be to auto-resize unless the user explicitly changes the size. From that point on, give them control of the window.
But if you look at the images in the linked page, there definitely appear to be some usability concerns here.
Microsoft releases whatever they damn well please and everyone has to upgrade or else they can't open docx files from work.
Support my political activism on Patreon.
On a related note, who thought it was a clever thing to make the reply and parent buttons stick out like a sore thumb among the comments on slashdot? I am looking at you CmdrTaco. /shakes fist
What, the concept that different people might actually have different preferences is "childish"? The Pidgin developers removed a feature that many people liked (myself included). When it was requested that they at least give an option for it, they outright refused. That is childish. The ability to fork a project if you think you can do better is one of the great strengths of Open Source software, because it means that the software can't get held back or bogged down by one person's vision of how things "must" be. You can't dismiss this strength as "childish" just because you personally don't need it on this one occasion.
Santa's suicide mission go!
Well, no, it's actually a little widget that you interact with via the mouse. I don't know what else it could legitimately be called.
DNA just wants to be free...
I can only assume you don't do much graphical UI development. "Widget" is a standard technical term used to refer to an element of a GUI. See for instance GUI Widget on Wikipedia.
The Safari text boxes are compound widgets (or metawidgets, if you like), which include a "resize handle" widget in their corner.
DNA just wants to be free...
"But what I do know is that if a version shipped with features nobody wanted, people would stop buying it. Instant negative feedback, especially the prospect of programmers losing their jobs."
What a load of bollocks, you need look no further than Office 12 for an example of a commercial developer losing their way and creating a UI feature that most users are not going to feel is a benefit (the ribbon). Arguably, Vista is the same. It's unlikely that Vista is going to fail as a commercial product, and even less likely that Office will.
"The problem with FOSS is... these guys don't get paid. If you don't like it, that's too bad you ungrateful bastard"
No, that's the problem with commercial proprietary software. It only takes one developer to change the course of an open source product, it may take many thousands of users voting with their wallets before a commercial vendor takes any notice at all, and even then they may decide that their new feature is so great they should proceed regardless. Which is pretty much where Pidgin is at the moment.
From where I sit the score is nil all.
And what's the inability to open two files, in different directories, with the same name?
Still. Now. After all these years. How is that a feature? And how difficult is it to fix?
Trying to become famous by taking photos. Visit my homepage please.